Shrinkwrap dependencies for releases

connectivedx / Phoenix

http://connectivedx.github.io/Phoenix/

33 stars 5 forks source link

Shrinkwrap dependencies for releases #139

Closed kamsar closed 9 years ago

kamsar commented 9 years ago

Currently if a package depends on another package with a non-exact version (e.g. ^1.0.0) the build can break later if a new version of that package is released that causes problems.

It looks like npm shrinkwrap solves this problem by pinning all dependency versions: http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/

ajmueller commented 9 years ago

@kamsar I'm finally getting some time to look at Phoenix stuff. I really like this idea and have marked it for the next release.

ajmueller commented 9 years ago

P.S. the shrinkwrap file for 1.2.1 is 13,720 lines and 778K. Yikes. Thoughts on the pros and cons of managing conflicts with this vs. the rarity that dependencies have actually caused issues for us?

kamsar commented 9 years ago

Dependencies blew up the build of 3-4 projects and necessitated some upgrades to latest versions unexpectedly to resolve. I don't really see shrinkwrapping as optional. On Wed, Jun 10, 2015 at 4:24 PM Alex Mueller notifications@github.com wrote:

P.S. the shrinkwrap file for 1.2.1 is 13,720 lines and 778K. Yikes. Thoughts on the pros and cons of managing conflicts with this vs. the rarity that dependencies have actually caused issues for us?

— Reply to this email directly or view it on GitHub https://github.com/connectivedx/Phoenix/issues/139#issuecomment-110945152 .

ajmueller commented 9 years ago

Looking at our chat log, it seems like you fixed one project by simply updating gulp-sass to 1.3.3 which was something I did in the 1.2.1 release of Phoenix. The strange thing is that locally we were not able to recreate the build issues on at least one project, but that is likely due to an older dependency getting installed locally early on in the project. Anyway, all the weirdness aside, shrinkwrapping will definitely be our best defense against these kinds of behaviors in the future.

As far as handling merge conflicts goes, I would say our best course of action is:

only handle conflicts in package.json
if conflicts arise in npm-shrinkwrap.json, resolve conflicts in package.json and rerun npm shrinkwrap --dev and commit whatever is produced there, simply treating npm-shrinkwrap.json as a compiled file

Thoughts?

kamsar commented 9 years ago

Yes. npm-shrinkwrap should be treated like a codegen file. One possible middle ground to keep the core more flexible would be to have shrinkwrapping be part of the 'I'm starting a project with Phoenix' steps. Though missing that step could cause you major pain later.

ajmueller commented 9 years ago

Yeah, I think it's best if we just include it as part of the core and add docs to the main readme file that explain the steps to take when you add new packages.

ajmueller commented 9 years ago

@kamsar I'm going to include this in the next release with the base NPM shrinkwrap documented and in use, but it may be worth research Über's own shrinkwrap in the future:

https://github.com/uber/npm-shrinkwrap