upgrade CLI

[stefanpenner]

Using ember should now be via npm v3 (older versions may work, but you wont get the goodies)

stuff

• shrinkwrap
• node 5
• use ambient npm (v3+)

note: yes the shrinkwrap file is massive

[stefanpenner]

failure was an intermittent sauce failure, re-running it.

@chancancode r?
@rwjblue r?

[chancancode]

👍 is it worth it to add an allow_failure build that deletes the shrinkwrap before running the build?

[stefanpenner]

@chancancode maybe, will that just be noise thought?

[stefanpenner]

@chancancode that can be added with a later PR

[chancancode]

I think it's actually good to know asap when an upstream change is breaking the build, so we can fix it, file a bug report, adjust our package.json, etc. Otherwise I am worried that it will get us stuck on old releases and rely on what upstream packages consider "accidental" behavior.

I believe Rails just unconditionally delete Gemfile.lock on all builds so we are always building against latest deps. But I guess the Rails deps are relatively stable (before Active Job, anyway :P) so it's less annoying.

I am not sure what's the best way to do it. Perhaps adding it to allow_failure just causes people to not look at it ¯_(ツ)_/¯

Another option is we can add a "latest deps" build only on the master branch and make it fail the build. It will probably be annoying enough that causes us to actually investigate the problem but still allow us to move forward (you can go into the build page to see that all but "latest deps" have passed and conclude that it's a upstream dep issue).

It'll probably end up annoying @rwjblue the most so maybe he should decide :P

[stefanpenner]

I believe Rails just unconditionally delete Gemfile.lock on all builds so we are always building against latest deps. But I guess the Rails deps are relatively stable (before Active Job, anyway :P) so it's less annoying.

this is slightly different, as ember ships bundled to consumers, rails ships as a series of gems that are resolved by the client. In-time we will also have this, but not currently.

[chancancode]

I believe Rails just unconditionally delete Gemfile.lock on all builds so we are always building against latest deps. But I guess the Rails deps are relatively stable (before Active Job, anyway :P) so it's less annoying.

this is slightly different, as ember ships bundled to consumers, rails ships as a series of gems that are resolved by the client. In-time we will also have this, but not currently.

I don't think that's relevant (I might be misunderstanding it). Rails is already built with the latest internal packages all the time (it uses paths in the Gemfile for the internal packages). Deleting the lock file is strictly about upstream dependencies like rack, mail, bcrypt and i18n. Which is also why the problem got worse after Active Job because it pulls in a lot of queueing libs as dev dependencies which are less stable than rack etc.

[stefanpenner]

@chancancode one of the benefits of detecting transient dependencies breaking the build, is to recognize consumers of the project are also affected. As ember.js is currently shipped bundled, this is largely not true as this bundle essentially serializes the "lock file" and ships it. Consumers of rails, do not benefit from rails's lockfile, as their app derives a new state based on the deployed Gemspec + the rest of their gemspecs.

As ember (hopefully) moves away from shipping itself totally bundled, we will likely also run into this type of issue (from consumers standpoint). But only for prod dependencies.

Now all i said, is pretty different from our (maintainers) perspective, we would likely like to know if one of our transitive deps has begun trolling us. For this one all dependencies could be affected, what makes me nervous is only the wide array of build tooling related transitive dependencies that may just be constant noise.

Im fine with someone adding a "allowed failures" branch that drops the shrinkwrap file, but because of the reasons i mentioned above I am not terribly motivated to do so yet. Once we stop bundling to consumers i become more interested.