Giters

emberjs / ember-cli-babel

Ember CLI plugin for Babel

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

V1Addon with ember-source@3.28 does not work with App with ember-source@v3.25

NullVoxPopuli opened this issue · comments

commented

I think it's because addons are resolving their capabilities local to them rather than the host app.
because setComponentTemplate (used in the output of co-located components), is referenced as Ember._setComponentTemplate in the app, and in the addon, referenced as: _component.setComponentTemplate (an import from the module (and real modules don't exist until ember-source@3.27)).

shouldn't ember-cli-babel ignore whatever is going on in the addon, and determine ember-source version from the host app?

commented

specifically, I think this works with app with ember-source@3.25.3, but not with app with ember-source@3.25.4

commented

I'll try 3.25.3 before attempting a PR

commented

I have the same problem on 3.25.3

commented

I don't understand the thing being reported here, can you be more specific? Have a reproduction?

commented

trying to get debug-info atm -- giving up on vscode on this machine 🙃

commented

The surface issue I'm trying to address is this error:

Could not find module @ember/component imported from (my module)
commented

ok, so after a bunch of debugging, I've determined that in booting my app,

  • every useModulesVersion usage is false (expected)` except when ember-source itself is building
    • same for the including the transform modules api babel plugin
      this is tied to this setting
      image
      which makes me thing this is intended behavior (and I gotta look elsewhere)
  • all invocations of emberVersionRequiresModulesAPIPolyfill return true (expected)

Odbservations:

  • @embroider/macros is involved pretty early on in the call stack, almost immediately after calling app.toTree() in the app's ember-cli-build.js
  • ember is building itself via buildEmberBundles
    this ember version matches the expected version (in monorepo, app has 3.25.4, addon has 3.28.8) 
    <app> on  <branch> 
❯ cat <path-to-root>node_modules/ember-source/package.json | jq '.version'
"3.25.4"

<app> on  <branch> 
❯ cat <path-to-root>/<addon-path>/node_modules/ember-source/package.json | jq '.version'
"3.28.8"

Observations

  • any time my conditional breakpoint(s) are hit (only thee times? (once for packages, dependencies, and headers)), I'm in the vendor tree (which makes sense, because ember-source is getting built)
  • all my breakpoints behave the same and have the same information in scope between a worktree that has a 3.28.8 addon in the monorepo and a worktree (upstream) that does not have 3.28.8
commented

can you make a repro? would it be a monorepo with two ember-source versions?

commented

Seems related to: emberjs/ember.js#19700

can you make a repro? would it be a monorepo with two ember-source versions?

yup, can do! 🎉

commented

yup, can do!

turns out, it's not so easy!
I'll have to compare my repro with whatever is going on with my work monorepo tomorrow

commented

Seems related to: emberjs/ember.js#19700

I just discover this issue, exact same for me, not working when my addon is linked (via yarn), but it works when referring the published addon.

commented

I'm facing this issue too, here's a repro https://github.com/prysmex/ember-eui/tree/update-3.24.0

  1. yarn
  2. cd site
  3. ember s

If you downgrade packages/core from ~3.27.2 to 3.26.2 it should work.