Mismatch between global vs. local ember version

[Fryie]

This is an issue that surfaced on our CI server after adding npm-shrinkwrap.json to the repository. ember install -g ember-cli, as far as I understand it, installs the most recent ember-cli version. However, if this version does not match (e.g. is newer than) the ember-cli version specified in the shrinkwrap file, ember will refuse to execute any commands. This means that I cannot execute the tests on the server. I see a couple of potential solutions:

• Upgrading ember-cli for the project as soon as a new version is available. That's not really a good solution in the general sense, although it's what I've done right now.
• Not using npm shrinkwrap. That causes a host of other problems, though.
• Not installing the global ember-cli on the CI server, instead just running npm install && bower install && .node_modules/ember-cli/bin/ember test. This would probably work, although it would preclude more clever solutions relying on potentially cached modules, such as ember version || (rm -rf node_modules/ bower_components/ && npm install && bower install). It also does not prevent similar issues arising on different developer machines.
• Having ember-cli-dependency-checker skip the version check for ember-cli. Not optimal, since some important stuff is going on in ember-cli that should probably be versioned (like the resolver).
• using the global ember-cli only for generating new projects and finding some way of always using the local ember-cli when inside a project - similar to what rails devs do when they run "rails new" for the generator, but then run every other Rails command through "bundle exec" (or binstubs or whatever). This also would probably break the caching of modules, forcing a reinstall, unless some other way of running ember's dependency checks could be found.

I could be missing some obvious, better solution. Any thoughts?

[dfreeman]

We basically do what you outline in the last bullet point. Both in CI and development, we make sure node_modules/.bin is near the beginning of the active PATH, so any project-local version of the CLI (or any other node package with a binary) gets preference over a global installation.

So far that's worked pretty well for us, though I'm not sure I understand your point about it forcing a reinstall. What do you mean about it breaking module caching?

[stefanpenner]

we make sure node_modules/.bin is near the beginning of the active PATH,

ember cli apps, ship with:

• npm run start
• npm run build
• npm run test

https://github.com/ember-cli/ember-cli/blob/master/blueprints/app/files/package.json#L10-L14

Which will automatically resolve ember via the node resolution algorithm.

so the approach you can take that will work 100% of the time without modifying the path is as follows:

1. clone project
2. cd project
3. npm install
4. npm run start|build|test

[dfreeman]

👍 That's great to know; didn't realize the stuff in the scripts hash would be resolved in a package-aware way.

[Fryie]

so the approach you can take that will work 100% of the time without modifying the path is as follows:

Thanks, I didn't know that. It's missing the "bower install" step, though. I guess this would help with CI issues, although for local development you'd probably still have to modify your path in order to execute "ember generate" etc. Is this documented somewhere? If not, I think this should be added.

ember-cli-dependency-checker advises to do the following on CI servers:

ember version || (rm -rf node_modules/ bower_components/ && npm install && bower install)

I'm guessing this is because some CI servers might be caching the node_modules folder between builds? But then again, this solution cannot really work if ember-cli is upgraded, because "ember version" will be run by a potentially wrong version of ember-cli? Is it advisable then to just always delete the node_modules folder?

[stefanpenner]

I guess this would help with CI issues,

Only guess, or does it?

although for local development you'd probably still have to modify your path in order to execute "ember generate" etc.

In local development, the suggested practice is to have a globally installed ember-cli which ships an executable that is compatible with whichever version of ember-cli is local to your node_modules directory

ember-cli-dependency-checker advises to do the following on CI servers:

ember version || (rm -rf node_modules/ bower_components/ && npm install && bower install)

that is strange advice.

I'm guessing this is because some CI servers might be caching the node_modules folder between builds? But then again, this solution cannot really work if ember-cli is upgraded, because "ember version" will be run by a potentially wrong version of ember-cli? Is it advisable then to just always delete the node_modules folder?

I would recommend never caching this, npm v2 does not correctly maintain node_modules in many scenarios. npm V3 does solve many of the issues though. Lets see how it plays in the wild once stable lands.

Is it advisable then to just always delete the node_modules folder?

yes, until such time that NPM actually works as expected.

[Fryie]

Only guess, or does it?

It does, although I need to delete the node_modules folder first - otherwise I run into strange problems with caching, as you mentioned.

that is strange advice.

Then I suggest dropping that line from the README, because it's very confusing.

Thanks for the advice. Seems npm is more broken than I imagined 😞

[stefanpenner]

If you have suggestions for the dep checker I would suggest opening an issue on that repo

[stefanpenner]

In going to close this. Some of these issues are fixed in npm v3, once that lands in stable nicer things will be possible. Until then we can't really do much more :(

[Fryie]

Thanks for the feedback. I will raise an issue in the dep checker repo. I think it would be nice if the pitfalls / steps discussed in this issue could somehow find their way into the documentation because I imagine other people might be as confused as I was.