10

I have a project in which several frontends sharing a common lib.

The module dependencies of those projects are managed by npm.

So, in the package.json of each of those projects I have :

  "dependencies": {
    "mylib": "file:../<...path...>/mylib",
    ...other deps...
  },

I use "mylib" for two purposes :

  • share some classes ;
  • share common dependencies (mostly, angular)

Until now, I was using npm 3.3.12 and after running npm install, the angular dependencies of mylib where right under the node_modules directory of my top level projects.

So, I had for instance

node_modules
    @angular
        core
        common
        ....
    mylib

Now, with npm 5.4.2, I have :

node_modules
    mylib
        node_modules
            @angular
                core
                common

This causes a lot of problems in my build process.It requires additional configuration of typescript, by adding directives such as :

"baseUrl": "",
"paths": {
    "@angular/common": ["node_modules/mylib/node_modules/@angular/common/"],
    "@angular/core": ["node_modules/mylib/node_modules/@angular/core/"],
    "@angular/compiler": ["node_modules/mylib/node_modules/@angular/compiler/"],
    "@angular/compiler-cli": ["node_modules/mylib/node_modules/@angular/compiler-cli/"],
    "@angular/forms": ["node_modules/mylib/node_modules/@angular/forms/"],
    "@angular/http": ["node_modules/mylib/node_modules/@angular/http/"],
    "@angular/platform-browser": ["node_modules/mylib/node_modules/@angular/platform-browser/"],
    "@angular/platform-browser/animations": ["node_modules/mylib/node_modules/@angular/platform-browser/animations/"],
    "@angular/platform-browser-dynamic": ["node_modules/mylib/node_modules/@angular/platform-browser-dynamic/"],
    "@angular/router": ["node_modules/mylib/node_modules/@angular/router/"],
    "primeng/primeng": ["node_modules/mylib/node_modules/primeng/primeng"],
    "rxjs/Rx": ["node_modules/mylib/node_modules/rxjs/Rx"]
    }

in tsconfig.json

It becomes really annoying when you have to do similar configurations for AOT, rollup, etc...

I tried to use npm dedupe do simplify this. As the projects have a lot of dependencies, it takes over 10mn for just one of them :

npm dedupe
...
...
removed 824 packages and moved 1020 packages in 623.196s

Is there a standard, efficient way to have the same kind of dependencies flattening as before ? npm dedupe does the job, but takes so much time that it is not an acceptable alternative.

Ludovic Pénet
  • 1,136
  • 1
  • 16
  • 32
  • Have you tried add all of those dependencies as peerDependencies within myLib? – Everest Oct 03 '17 at 09:40
  • I do not get how it would help me. I want to specify the dep in myLib. With peerDependencies, I would have to add those deps in my top level projects, no ? And I have stuff dependending on those dependencies in "myLib"... – Ludovic Pénet Oct 03 '17 at 10:03
  • Take a look at https://nodejs.org/en/blog/npm/peer-dependencies/ I think in your case you want these dependencies in both myLib as a peerDependency and in your other projects – Everest Oct 03 '17 at 10:16
  • 2
    Try switching to `yarn` instead. Install it then remove your `node_modules` folder and do `yarn install --flat`. Or just `yarn install` should still do the dedupe. – Duncan Oct 03 '17 at 10:18
  • @Duncan : yarn install (without --flat) did the job. You made my day. Propose this as an answer so that I can credit you. – Ludovic Pénet Oct 03 '17 at 11:21
  • Everest : no, I do not want to have to repeat them in the top level projects. – Ludovic Pénet Oct 03 '17 at 11:22
  • 1
    `npm dedupe` was immensely helpful for me to find here, thank you – jimmont May 11 '18 at 03:22

1 Answers1

5

As an alternative to npm you might want to switch to using yarn. That should dedupe modules by default. Start by removing your existing node_modules folder then just do yarn install.

You can also force yarn to do a flat install (yarn install --flat), but in this case it may be sufficient just to do the plain install.

Add the yarn.lock file to version control and any other checkout will then be locked down to the same module versions (unless they do yarn upgrade).

Duncan
  • 92,073
  • 11
  • 122
  • 156
  • 1
    Dealing with local dependencies, with dev team members using a variety of OS's, yarn was the only reliable solution to this issue. – Tony Chiboucas Jul 06 '18 at 19:57