Resolving classes from an addon, within an engine, does not work

[alexlafroscia]

I came across the need to resolve a class name from an addon today, and was delighted to see that, generally, this is supported!

ember-css-modules/lib/resolve-path.js

Line 40 in 2e30029

function resolveExternalPath(importPath, options) {

However, I ran into an issue with Ember Engines that's blocking me from using this:

• The class I want to compose from is in an addon
• That addon is a dependency of an engine; the stylesheet that is trying to compose from the addon lives here
• That engine is mounted into my application; the application does not have a direct dependency on the addon (nor should it)

Within that resolveExternal function linked to above, options.project is pointing to the application not the engine, so the addon can't be resolved.

The application does not have a direct dependency on that addon, and I don't want to introduce one, or we'll loose out on the benefits of lazy-loading that whole addon.

[dfreeman]

Funnily enough, that bug has been in ember-css-modules forever, and we've been using addon resolutions that entire time and literally ran into this bug for the first time today.

You're exactly right: passing project there is a mistake; when we're operating on an addon it should be the parent addon rather than the root project.

[alexlafroscia]

Huh! How about that!

A tiny bit of extra context, that likely isn't necessary but I forgot to include previously: this was what gave away the issue when I was digging into it earlier

the ownerName and the project are talking about different packages

[dfreeman]

Yep. You may already know this, but "owner" in this code (which predates Ember's use of the word, but now it's kind of confusing) roughly means "the app or addon that ember-css-modules is acting on behalf of", while in Ember CLI project always refers to the root thing, comprised of the host app and its whole tree of addons.

I have some time blocked off tomorrow to do some cleanup here and try and make sure our Broccoli output is stable; I'll aim to get a fix for this in as well.

[alexlafroscia]

Sweet! I'm happy to work on the issue too (or with you) since we'd love to start composing classes from an addon this way in our engines.

[dfreeman]

Thanks for the offer! I ended up having @kehphin and @0xadada copilot on a bug squashing session this afternoon, and just published a fix in v1.0.3.

[alexlafroscia]

Awesome!