13 ms·
Even more important, npm doesn't reliably reproduce builds. Different runs of the same shrinkwrapped build could either fail or succeed -- which is odd given th
by yunong 11y ago
Even more important, npm doesn't reliably reproduce builds. Different runs of the same shrinkwrapped build could either fail or succeed -- which is odd given that builds should be deterministic. Additionally, shrinkwrap is also broken in the same way.
This is the first time I've heard of ied, a little competition could go a long way!
- krisdol 11y agoCould you expand on that? What causes it to be nondeterministic? I haven't had that experience but it's the second time I've read someone reference this behavior
- yunong 11y agoI have a project that's shrinkwrapped. I check out a new copy of the project and run `npm install`. My co-worker does the exact same thing, his fails, yet mine successfully builds. An install of a shrink-wrapped should be deterinistic, i.e. either succeed or fail, but not both.
- Wintamute 11y agoFrom that doc page it sounds like that should be deterministic? Even without shrinkwrapping, a fresh install from package.json with empty node_modules should be deterministic. > The npm install command, when used exclusively to install packages from a package.json, will always produce the same tree. This is because install order from a package.json is always alphabetical. Same install order means that you will get the same tree. > You can reliably get the same dependency tree by removing your node_modules directory and running npm install whenever you make a change to your package.json. Maybe you're experiencing a bug, rather than some in-grained non-determinism in npm?
- madeofpalk 11y agoMy understanding is that even when you fix your dependencies to exact versions, your dependencies probably haven't so without shrink-wrap you'll never know _exactly_ what gets installed.
- kemitchell 11y agoWhat's the error on the build that fails?
- dandelany 11y agoHere are details from the docs: https://docs.npmjs.com/how-npm-works/npm3-nondet https://docs.npmjs.com/how-npm-works/npm3-nondet
- kemitchell 11y ago> You can reliably get the same dependency tree by removing your node_modules directory and running npm install whenever you make a change to your package.json. https://docs.npmjs.com/how-npm-works/npm3-nondet https://docs.npmjs.com/how-npm-works/npm3-nondet
- krisdol 11y agoThat explains why I haven't experienced it -- our projects' npm scripts to build packages wipe out that folder before building.
- juandazapata 11y agoThat's frustrating, I got bitten by that a couple of times. I'm wondering when will they add a LOCKFILE like every other build system out there :'(
- mbell 11y agoI agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.
- sync 11y agoMix, Erlang's package manager (used by Phoenix / Elixir) Cargo, Rust's package manager Meteor
- SEMW 11y ago> Mix, Erlang's package manager (used by Phoenix / Elixir) Slight nitpick: Mix is part of Elixir, I've never seen a (non-elixir) erlang project that use it. Don't think erlang has an equivalent officially blessed tool, but the most popular one is rebar / rebar3. (While I'm nitpicking: mix and rebar are more build & dependency managers; mix uses hex for package management. I believe rebar3 can also use hex. In ruby terms, mix ~ bundler (among other things); hex ~ rubygems).
- geerlingguy 11y agoComposer (PHP) too.
- deleted 11y ago[deleted]
- strmpnk 11y agoThese come to mind: rebar3 (Erlang), mix (Elixir), composer (PHP), elm-package (via elm-stuff/exact-dependencies.json).
- stormbeta 11y ago
- lintiwen 11y agosame issue here. this non-deterministic behavior is really fxxked up. there's one time that our building process suddenly begin to fail, spend a few hours on the issue, and it turned out to be one of the babel-core patch release is broken. some of the very fundamental designs of npm is seriously wrong.