Open achambers opened 3 years ago
Heyo ππΌ
Are you using yarn?
Can you give https://github.com/salsify/ember-cli-dependency-lint and https://github.com/atlassian/yarn-deduplicate a try?
I suspect that yarn did not optimize / deduplicate the yarn.lock
when ember-link
was installed. So now you have multiple versions of ember-auto-import
, and as it seems, the wrong version got loaded first and thus is the "main" version.
If this doesn't fix it, e.g. by upgrading all to the same (e.g. latest 1.11.2
), try using a yarn resolution to enforce a specific version for all dependencies.
Hi @buschtoens π
Thanks for stepping in. Yep, I figured itβs to do with the version of ember-auto-import being used. Was finding it hard to determine exactly which version was being used when it worked and when it failed. I tried using yarn resolutions but it didnβt seem to make any difference π€·ββοΈ
I do use yarn so will give your suggestions a try and report back how I get on.
Thanks again for your prompt reply :)
@buschtoens I'm trying to reconcile the fact that ember-cli-dependency-lint mentions that it ignores ember-auto-import by default (https://github.com/salsify/ember-cli-dependency-lint#build-time-addons) citing:
Different addons your app uses should be able to compile using whatever tooling they like without conflicting with one another.
I'm not super familiar with how ember-auto-import works, but do you think that if I try and use the dependency-lint it would make sense for me to ensure it does lint ember-auto-import?
Ok, I've spent a bunch of time installing, and then reinstalling dependencies and it seems that the version of ember-auto-import that seems to work, when pinned, and after ember-link has been installed is 1.5.2
. Anything after that seems to give the error.
I sure would love some suggestions on where to go next with this π€
Ok, another update. I went back to master
, from before I installed ember-link and can replicate this. I noticed that the versions of ember-auto-import that were installed ranged from 1.5.2
(from one of our dependencies) to 1.10.1
(from our dev dependency which specified ^1.8.0
.
I pinned (via the resolutions
prop of the package.json file) every version of ember-auto-import starting at 1.5.2
and can confirm that the last working version was 1.10.0
and then pinning 1.10.1
breaks when starting the ember server.
So, what is it about the changes between these two versions (https://github.com/ef4/ember-auto-import/compare/v1.10.0...v1.10.1) that's causing the error I posted in the issue description? I'm feeling out of my depth at this point so any advice would be super appreciated.
1.5.2 β 1.5.3 β 1.6.0 β 1.7.0 β 1.8.0 β 1.9.0 β 1.10.0 β 1.10.1 β 1.11.0 β 1.11.1 β 1.11.2 β 1.11.3 β
(Update: Added 1.11.3
as another non-working version)
Apologies for the stream of consciousness here. Just trying to get all the facts down in the hope someone can help me.
The error I am seeing is exactly this https://github.com/emberjs/ember-test-helpers/issues/961
I know this is in a difference repo but it was linked to from https://github.com/ef4/ember-auto-import/issues/337
I have upgraded ember-qunit
to the latest and the installed qunit
and @ember/test-helpers
(due I think to the fact that ember-qunit no longer brings them in). I've confirmed that the version of @ember/test-helpers
is >=2.2.1
which apparently contained the fix.
Still no joy though.
That issue in the ember-test-helpers still doesn't explain to me why 1.10.0
works and 1.10.1
doesn't so I'm completely flummoxed π€
Thanks for all the analysis you've done already. It's really helpful. I don't know, whether I can find the root cause, but this surely is enough for others to go off on.
@buschtoens I'm trying to reconcile the fact that ember-cli-dependency-lint mentions that it ignores ember-auto-import by default (salsify/ember-cli-dependency-lint#build-time-addons) citing:
Different addons your app uses should be able to compile using whatever tooling they like without conflicting with one another.
I'm not super familiar with how ember-auto-import works, but do you think that if I try and use the dependency-lint it would make sense for me to ensure it does lint ember-auto-import?
Oh, I didn't recall, that ember-auto-import
is ignored by default. It makes total sense, because ember-cli-dependency-lint
is meant to guard against conflicting versions in the output bundle, and not with the build tools creating the bundle, as these tools usually all operate in isolation in the scope the addon they are a dependency of.
This is not completely true for ember-auto-import
, as all instances talk with one another. IIRC the first instance of ember-auto-import
that loads is the "winner" and becomes the main instance that all other instances delegate to.
This explains, why installing a new addon that has a dependency on ember-auto-import
can cause an out dated or unexpected version to become the main one.
So, what is it about the changes between these two versions (v1.10.0...v1.10.1) that's causing the error I posted in the issue description? I'm feeling out of my depth at this point so any advice would be super appreciated.
Hm, looking at the commits there appear to be no relevant changes at all. Maybe there is an off-chance, that the resolution is not working 100 % correct, or that there are transitive dependencies, which don't resolve correctly?
Have you tried verifying this bit of https://github.com/ef4/ember-auto-import/issues/337#issuecomment-756541525?
webpack/webpack#10843 seemed to provide a bit of a clue.
And when I run ember with the debug flags for auto-import, I see this
ember-auto-import:bundler extraWebpackConfig {"module":{"rules":[{"test":{},"use":["style-loader","css-loader"]},{"test":{},"use":["style-loader","css-loader"]}]}} +0ms
So it looks like something is causing the rule to appear twice.
If I look through the process using node debugger, I can see that my ember application ends up in the
Set
of packagesthis.options.packages
twice.
I think that this is a likely cause. If so, we can try to dig in deeper there and find out, why that's happening.
IIRC the first instance of ember-auto-import that loads is the "winner" and becomes the main instance that all other instances delegate to.
It's not precisely the first copy, it's the first copy of the newest version that's present. But yes, that means it's OK to have multiple versions floating around.
I would debug this further by getting into a debugger at node_modules/mini-css-extract-plugin/dist/loader.js:209:23
and working back from there to see what "Didn't get a result from child compiler" really means.
Taking a guess, I suspect this is likely to be a package manager problem (some package is seeing a version of another package that it shouldn't be.)
Thanks @buschtoens and @ef4 for your suggestions. I'll dig deeper taking on your thoughts and see where I end up. Will report back here to, hopefully, tie up the loose ends for anyone else that finds themselves here.
Ok, I'm getting closer, I think. I have verified that I am also seeing this:
webpack/webpack#10843 seemed to provide a bit of a clue.
And when I run ember with the debug flags for auto-import, I see this>
ember-auto-import:bundler extraWebpackConfig {"module":{"rules":[{"test":{},"use":["style-loader","css-loader"]},{"test":{},"use":["style-loader","css-loader"]}]}} +0ms
So it looks like something is causing the rule to appear twice.
If I look through the process using node debugger, I can see that my ember application ends up in the Set of packages this.options.packages twice.
When using ember-auto-import v1.10.0
, I get this:
{
"plugins": [
{
"_sortedModulesCache": {},
"options": {
"filename": "vendor.css",
"ignoreOrder": false,
"chunkFilename": "[id].vendor.css"
},
"runtimeOptions": {
"linkType": "text/css"
}
}
],
"module": {
"rules": [
{
"test": {},
"use": [
"/Users/wadewilson/Code/phorest/implement-web-only-designs/node_modules/mini-css-extract-plugin/dist/loader.js",
"css-loader"
]
},
{
"test": {},
"include": {},
"type": "javascript/auto"
}
]
}
}
When using ember-auto-import v1.10.1
, I get this: (you can see duplication that isn't present in the above)
{
"plugins": [
{
"_sortedModulesCache": {},
"options": {
"filename": "vendor.css",
"ignoreOrder": false,
"chunkFilename": "[id].vendor.css"
},
"runtimeOptions": {
"linkType": "text/css"
}
},
{
"_sortedModulesCache": {},
"options": {
"filename": "vendor.css",
"ignoreOrder": false,
"chunkFilename": "[id].vendor.css"
},
"runtimeOptions": {
"linkType": "text/css"
}
}
],
"module": {
"rules": [
{
"test": {},
"use": [
"/Users/wadewilson/Code/phorest/implement-web-only-designs/node_modules/mini-css-extract-plugin/dist/loader.js",
"css-loader"
]
},
{
"test": {},
"include": {},
"type": "javascript/auto"
},
{
"test": {},
"use": [
"/Users/wadewilson/Code/phorest/implement-web-only-designs/node_modules/mini-css-extract-plugin/dist/loader.js",
"css-loader"
]
}
]
}
}
And here's a diff of the two:
So, this is leading very much to this being the same issue as reported in https://github.com/emberjs/ember-test-helpers/issues/961. The funny thing though is that I have tried to update the version of @ember/test-helpers a few days ago but it didn't seem to work.
I'll try that path again to make sure I didn't do something incorrect.
(Also, I still can't make sense in my head why updating from ember-auto-import 1.10.0
to 1.10.1
would cause this if it isn't actually ember-auto-import that's at fault. I can't connect those dots in my mind yet).
Ok, so, upgrading the version of @ember/test-helpers
, as is the suggested solution in https://github.com/emberjs/ember-test-helpers/issues/961 does not seem to work for me. I can't place why that might be.
The one difference is that I am using Ember 3.23.1, but all the reports in the issue describe it from happening when upgrading to 3.24.x. I suspect that this is the case because 3.24.x introduces ember-auto-import 1.10.1. Whereas I've specifically pinned that version my 3.23.1 app.
And, because I'm on 3.23.1 I've had to do the following to upgrade to the latest version @ember/test-helpers which supposedly has the fix.
I guess now it might be time to put a comment in https://github.com/emberjs/ember-test-helpers/issues/961 to ask for help. Still, I still would like to understand why upgrading from ember-auto-import 1.10.0 to 1.10.1 is the trigger for this error.
Ah, so if this was being caused by duplicated webpack config, then it may be fixed by https://github.com/ef4/ember-auto-import/pull/377
@ef4 Oh, that looks promising. I see it's not been released yet. I'll keep an eye out for v1.11.3 to verify if it fixes the issue.
@ef4 Are you able to release master
so I can verify if #377 fixes this?
Hi @ef4 π
I'm pretty sure I'm in the right place to ask about this bug, but if not, please let me know where I might be better off looking. Hoping I can find some joy here though.
Here's the deal.
I'm currently using Full Calendar in my app. I initially had a bit of trouble running it because it imports CSS in to JS, but I managed to get it working following a thread of instructions starting in https://github.com/ef4/ember-auto-import/issues/337
As a result I have ended up with the following ember-cli-build.js config:
My app is currently using ember-auto-import@v1.10.1 things were working fine.
However, after installing https://github.com/buschtoens/ember-link, and making no other changes, the build barfs with:
I noticed that ember-link pulls in ember-auto-import@v1.11.2.
Can you point me in the direction of what might be causing this build error after having simply installed the ember-link addon?
If there is any extra info I can provide, please let me know.
Thanks in advance π