2

I am using angular-cli and building a SPA using Angular2. I have a Jenkins build system for my application where in every time there is a change in my project repository, a build is triggered which basically deletes the entire node_modules folder and then does npm install followed by my build process. All this is done remotely on a Linux machine.

Problem:
Now the issue I am facing is that of the secondary and tertiary dependencies. Most of the dependencies (if not all) I am installing using npm have their own packagae.json file which in turn have their own, so on & so forth. So even if I freeze the versions in my main package.json file by removing carets or tildes, there is no way I can control the version of the secondary and tertiary dependencies. This is resulting into a lot of UNMET PEER DEPENDENCY errors as one dependency needs one version of the same component while the other one needs another!

Question:
So my question is, how do I make sure that this does not happen and achieve a stable dependency installation?

theHeman
  • 505
  • 1
  • 6
  • 26

1 Answers1

2

You can keep your package.json as is and run npm shrinkwrap, which will create a new file npm-shrinkwrap.json with the exact versions of all package hierarchy installed at the time you ran it.

If you commit this file, the next time you run npm install, npm should detect the file and respect it.

Documentation:
https://docs.npmjs.com/cli/shrinkwrap

P.S.

Another option that works similarly is Facebook's yarn npm client (a tool similar to the local npm tool).

It uses its own yarn.lock file, and it's much faster as it caches dependencies in its own shared cache making next installs much faster.

But for your use case on the build server, it might be harder to set it up or so. That's why I emphasized the answer on npm itself.

Meligy
  • 35,654
  • 11
  • 85
  • 109
  • 1
    Just to make sure I have understood what you are saying correctly, `npm shrinkwrap` command need to be run only once and then it will generate the `npmshrinkwrap.json` file which I will check-in. After that once my build server pulls it (syncs up with the remote repo), it will respect the per say locked-in state of the dependency version, right? – theHeman Dec 27 '16 at 05:53
  • Exactly. Give it a try first before you mark this as a correct answer ;) – Meligy Dec 27 '16 at 07:57
  • Can you please tell me what will be the best way to test this? – theHeman Dec 27 '16 at 10:29
  • One thing you can do is run `npm shrinkwrap`, then change `typeScript` version in `package.json` manually to `"^2.0.10"` (note `^`, which matches 2.1.x), and run `npm install` again (maybe even clean `node_modules` first). Then run `npm ls typescript` and see if it's the same version (2.0.10) not 2.1.x. – Meligy Dec 27 '16 at 14:28