I have a project using monolithic repositories. Each packages has his own package.json file to manage dependencies for the said package. I'm using <code>lerna</code> to install package in all "sub-packages" of our monorepo app. The current project structure looks like this <pre class="prettyprint">Project/ | package.json | node_modules/ |- packages/ |-- package1/ |--- package.json |--- node_modules/ |-- package2/ |--- package.json |--- node_modules/</pre> I'm looking into a way of generalize common dependencies in the root node_modules folder so each packages doesn't pull his own copy of a node package when running <code>lerna exec -- npm install</code> but instead use the one that is at the root of the monolithic repo so we avoid installing the same package in multiple repo, hence, reducing the size of the project. I've seen some solution including to make some symlinks between project but that's doesn't seems to be an exact science since symlink support is very OS opinionated. Also, this doesn't seems to be a supported way of doing it. Currently, we're just at the beginning and after running <code>lerna exec -- npm install</code> the project is already around 350mb on disk and pulling everything from npm takes around 5 minutes the first time. As the project will grow over time, this time will also extend over time... So to resume everything, I'm looking for a way to extract the common dependencies in a node_modules folder at the root of the repo and make the sub-packages pull from this folder their common dependencies instead of getting their own copies everytime.

Lerna recently added a <code>--hoist</code> option that looks like it provides exactly what you were looking for here. It installs external dependencies at the repo root so they're available to all packages. Binaries are linked into dependent package <code>node_modules/.bin/</code> directories so they're available for npm scripts. It can be passed on the command-line or added to <code>lerna.json</code> for durable configuration. Documentation is available here: https://github.com/lerna/lerna#--hoist-glob

Monolithic repo and multiple node

I have a project using monolithic repositories. Each packages has his own package.json file to manage dependencies for the said package. I'm using lerna to install package in all "sub-packages" of our monorepo app.

The current project structure looks like this

Project/ 
| package.json
| node_modules/
|- packages/
|-- package1/ 
|--- package.json 
|--- node_modules/
|-- package2/
|--- package.json
|--- node_modules/

I'm looking into a way of generalize common dependencies in the root node_modules folder so each packages doesn't pull his own copy of a node package when running lerna exec -- npm install but instead use the one that is at the root of the monolithic repo so we avoid installing the same package in multiple repo, hence, reducing the size of the project.

I've seen some solution including to make some symlinks between project but that's doesn't seems to be an exact science since symlink support is very OS opinionated. Also, this doesn't seems to be a supported way of doing it.

Currently, we're just at the beginning and after running lerna exec -- npm install the project is already around 350mb on disk and pulling everything from npm takes around 5 minutes the first time. As the project will grow over time, this time will also extend over time...

So to resume everything, I'm looking for a way to extract the common dependencies in a node_modules folder at the root of the repo and make the sub-packages pull from this folder their common dependencies instead of getting their own copies everytime.

Should the node_modules directory be committed to your project's git repo?

You should not include folder node_modules in your . gitignore file (or rather you should include folder node_modules in your source deployed to Heroku). If folder node_modules: exists then npm install will use those vendored libraries and will rebuild any binary dependencies with npm rebuild .

Why you shouldn't commit node_modules?

If you commit node_modules it means any developer can change any dependency with ease (it's called “monkey patching”), and this definitely will lead to a problem: when you will update this changed dependency, old changes will be lost, and you have to solve that.

Is Mono repo better?

A monorepo removes barriers and silos between teams, making it easier to design and maintain sets of microservices that work well together. Standardization. With monorepos, it is easier to standardize code and tooling across the teams.

What is a mono repository?

A monorepo is a version-controlled code repository that holds many projects. While these projects may be related, they are often logically independent and run by different teams. Some companies host all their code in a single repository, shared among everyone.

Lerna recently added a --hoist option that looks like it provides exactly what you were looking for here. It installs external dependencies at the repo root so they're available to all packages. Binaries are linked into dependent package node_modules/.bin/ directories so they're available for npm scripts.

It can be passed on the command-line or added to lerna.json for durable configuration.

Documentation is available here: https://github.com/lerna/lerna#--hoist-glob

Monolithic repo and multiple node_modules folder

Tags:

npm

node-modules

lerna

Marc-Andre R.

People also ask

1 Answers

Bo Borgerson

Recent Activity

Donate For Us