V1Addon with [email protected] does not work with App with [email protected]

[NullVoxPopuli]

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 [email protected])).

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

[sly7-7]

specifically, I think this works with app with [email protected], but not with app with [email protected]

[NullVoxPopuli]

I'll try 3.25.3 before attempting a PR

[NullVoxPopuli]

I have the same problem on 3.25.3

[rwjblue]

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

[rwjblue]

FWIW, we do use whatever the project has (ember-source wise)

https://github.com/babel/ember-cli-babel/blob/315df8af07bdc755c7529578dd48f5e25e2930d9/index.js#L88

https://github.com/babel/ember-cli-babel/blob/315df8af07bdc755c7529578dd48f5e25e2930d9/lib/get-babel-options.js#L55

https://github.com/babel/ember-cli-babel/blob/315df8af07bdc755c7529578dd48f5e25e2930d9/lib/babel-options-util.js#L165-L166

https://github.com/babel/ember-cli-babel/blob/315df8af07bdc755c7529578dd48f5e25e2930d9/lib/babel-options-util.js#L133-L141

[NullVoxPopuli]

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

[NullVoxPopuli]

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

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

[NullVoxPopuli]

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
    
    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

[rwjblue]

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

[NullVoxPopuli]

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! 🎉

[NullVoxPopuli]

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

[NullVoxPopuli]

ooo, I did it. link here: https://github.com/NullVoxPopuli/repro-ember-pre-and-post-3-27-compat

@rwjblue ^

[sly7-7]

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.

[betocantu93]

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.