Should we have node_modules committed? about jquery-release HOT 9 CLOSED

shrinkwrap? Although i remember there was some issues with it.

This apparently saves some dangerous/places a release could go wrong situation

Was there a precedent?

from jquery-release.

We can just have the release script install its own dependencies as the first step.

from jquery-release.

Sure. There are definitely disadvantages with having it in the repo.

from jquery-release.

Most dependencies are nailed to a specific version which is good, so having it install dependencies should be relatively low risk.

from jquery-release.

@dmethvin

Most dependencies are nailed to a specific version which is good, so having it install dependencies should be relatively low risk.

The problem is that only direct dependencies are specified this way. You can't count on npm install done some time later producing the same dependency tree.

@gnarf

I think that it's going to create problems for cross platform if the deps ever end up with compiled gyp modules for instance.

This is supposed to be taken care of by node-gyp rebuild. That said, npm@3 will dedupe by default so the current tree won't be what it'd produce; the logical dependency tree will be decoupled from the directory one. I'm not sure how it'll play with dep structure created via [email protected] or 2.x (perhaps @othiym23 would know more).

Shrinkwrap was created for this use case. It still has some problems, e.g. it doesn't warn against mismatches between package.json & npm-shrinkwrap.json (it just ignores the former), it doesn't work with npm install --save out of the box etc. This, again, should be taken care of in the nearby future but we're not there yet.

from jquery-release.

@dmethvin that assumes any dependencies of our dependencies use fixed versions. This is generally not true.

from jquery-release.

@arschmitz @mzgol Oh yeah I always forget that you're only as unvarying as your sloppiest dependency. Shrinkwrap may be a safer option.

from jquery-release.

@dmethvin @arschmitz fixed deps are not ideal, but it has is a very low risk that the same features of the dependancy wouldn't work the same way, since deps of the dep are encapsulated.

I wonder if somebody actually face any inconsistencies with fixed deps, yeah, theoretically it's possible, but practically?

I think if there wasn't any issues with it, we shouldn't try to fix something that's not broken. shrinkwrap is pretty radical.

from jquery-release.

I would recommend testing shrinkwrap as a group and seeing how you feel about the result. @mzgol is right in that we're making some improvements to shrinkwrap in npm@3, and he's also right that it's probably going to be a little while until npm@3 is stable enough for this use case. In the meantime, if there are bugs that block you using it to distribute jQuery, we're happy to work with you to smooth out those edges (especially if there are patches included).

Because npm has to bootstrap itself, all its production dependencies are bundledDependences and checked into Git; it also doesn't / can't have any native modules in the dependencies. Those two constraints sort of cancel each other out, but there are special tests cases to ensure that node_modules is in sync with both bundledDependencies and dependencies. In practice, this is a pretty low-key workflow, and it ensures that everyone doing releases is releasing the same bits, but it doesn't play very nice with native modules and does require a certain amount of extra discipline.

from jquery-release.