Properly detect host ember-cli version. #190
Conversation
When running in a linked environment, the standard `require.resovle` technique to determine the currently running ember-cli version does not work properly (because the linked addon's ember-cli dev dependency will be found instead of the _actual_ running ember-cli from the project). The most common symptom of this issue is that modules are "double transpiled" (e.g. you have an AMD wrapped module _inside_ of another AMD wrapper).
|
shouldn't we fix this in ember-cli-version-checker instead? |
|
The issue is that it depends. If you are trying to detect the currently running processes version of ember-cli you do the thing I’m doing here, but Ember-cli-version-checker is mostly just checking what is installed within the specific root. In other words, checking the running processes version of ember-cli isn’t always correct... |
please elaborate 🤔 |
|
It is correct in this case because the running processes Ember-cli will be controlling any build stuffs, however you could easily be running ember-cli-version-checker from within a process started (for example) with the globally installed ember-cli. In that scenario you want to detect the installed version, not the running one.... |
|
I’m also not sure that I like the idea of special casing specific packages in the version checker (yes I know we made a special method for Ember itself). IMHO, the majority of the time, what it does now is correct, and apecial casing sucks (generally speaking). I’m happy to move this to the version checker if you feel very strongly. I just want to unblock folks currently being trolled by the bug I’m fixing. |
|
Discussed with @Turbo87 in slack, we are both 👍 on fixing the user facing issue here first and will circle around later to decide if |
Update `workerpool` to latest (avoiding deprecations)
When running in a linked environment, the standard
require.resovletechnique to determine the currently running ember-cli version does not work properly (because the linked addon's ember-cli dev dependency will be found instead of the actual running ember-cli from the project).The most common symptom of this issue is that modules are "double transpiled" (e.g. you have an AMD wrapped module inside of another AMD wrapper).