Building addon with 1.3.0-beta.1 fails with message Unable to resolve styles from addon ; is it installed?
#166
Comments
|
There's a "bug" in how the error message for missing / unresolvable ember-css-modules/packages/ember-css-modules/lib/resolve-path.js Lines 40 to 47 in bf70611 You are trying to Can you try adding |
|
🤔 We shouldn't be entering @FabHof figuring out what |
|
Thanks for the responses, I did some digging and It seems to be an issue with a virtual module. {
importPath:"colors"
}I have the following in my index.js: included(app) {
// ...
this.options = Object.assign({}, this.options, {
cssModules: {
virtualModules: {
colors: {
primary: config.primary || '#a55176'
// some more colors
}
}
}
});
this._super.included.apply(this, arguments);
}Seems the options are not loaded:
|
|
@dfreeman Could I get a quick status update on this? Is there currently any development in progress? I could try to dig into the code and find a fix, if you need help. But of course I don't want to get in the way of anything. |
|
Hi @FabHof, thanks for your patience on this! After attempting several different approaches with this, I don't think there's a path forward that allows addons to continue setting their I've opened #186, which improves the awful error message you originally reported at the top of this thread, and also updates the guidance in the virtual modules documentation to use the setupPreprocessorRegistry(target) {
if (target === 'parent') {
let parentOptions = (this.app || this.parent).options || {};
let config = parentOptions.myAddon;
this.options = Object.assign({}, this.options, {
cssModules: {
virtualModules: {
colors: {
primary: config.primary || '#a55176'
// some more colors
}
}
}
});
}
}That should allow you to update the options for your addon's ECM config before it's read. #153 (comment) has a brief thread around whether to consider this timing update a breaking change from a semver perspective. I'd love to avoid gating Embroider + colocation support behind a major upgrade for folks, but it's hard to know how often people are doing things like this in private packages that may get burned by the change (even if this timing technically isn't strongly-defined). |
|
Thanks @dfreeman for the good explanation. Sadly the workaround does not seem to work for the current 1.3.0-beta.1, it works for 1.2.1 however. Should it work for the current beta? |
|
@FabHof it should! 🤔 Is the addon in question publicly available? That approach worked fine in the dummy addon I tested it out with. |
|
@dfreeman I created an example that does not build (at least for me): |
|
Thanks @FabHof, that's super helpful! I think I was watching for the wrong hooks to be hit in my own local testing 😅 In the end I think I've come up with an approach to restore the previous timing for computing options. I've updated #186 to include that change and am verifying the test suite continues to pass, but hopefully should have a release for you that fixes everything that's come up in this thread within the next day or so 🙂 |
I updated my addon with pod-structure and ember-css-modules-sass to use ember-css-modules 1.3.0-beta.1, because I wanted to start to move from pod-structure to template co-location
Now
ember buildfails withUnable to resolve styles from addon ; is it installed?ember build output:
Packages I have installed:
The text was updated successfully, but these errors were encountered: