15

It seems like in a Nrwl/Nx workspace there is only a single package.json file. Now if we have multiple applications, each dependent on different packages, then we have to include all of those package in the single package.json file and wouldn't that increase the size of all the apps when they're built? (presumable vendor.js file).

For example if app-1 depends on d3 and app-2 depends on ag-grid libraries, wouldn't both of these libraries be included for both app-1 and app-2 unnecessarily? When the user of app-1 visits the app, ag-grid wouldn't need to be loaded for them.

Am I correct in my understanding or am I missing something? If my assumption is correct, is there a way to solve this?

How about lazy loaded libraries? For instance an "admin" library which is only available to some users (with admin role) may need certain graphing packages, which wouldn't have to be loaded for all the users.

Thank you.

Improve this question

2 Answers 2

Reset to default
14

One of the benefits of using nrwl/nx is the single package.json file. Using a single package.json is great because when you need to upgrade something like rxjs you only have to do it once and your entire codebase it running on the same set of dependencies.

It doesn't effect the size of the compiled code because an app will only include the code it uses thanks to webpack bundling and tree shaking. So there is no risk of D3 showing up in a bundle for an app that doesn't use it. In actuality you could have every npm package listed in your package.json and it wouldn't effect your bundle size.

nrwl/nx is 100% intended to use only one package.json file. Don't try to break it up if you are using nx.

Improve this answer
3
  • 1
    Thank you. I tested this by adding D3 to package.json and noticed that the size of dist folder didn't increase. I then used it in one of my lazy loaded libs and it seems like only the size of that lib in dist folder went up, which is great. Thanks again for clarification.
    – Esfandiar
    Commented Oct 11, 2018 at 15:26
  • 7
    I would argue. Single package.json has significant downsides: 1. It grows dramatically when you have multiple apps for different platforms, so it's hard to manage those dependencies. I have separate angular web app, and Ionic mobile app. For mobile app I need ionic-specific dependencies that are not needed anywhere else. If I then need to refactor, or even remove one of the apps, it is painful to detect which depencencies in package.json it depended on. 2. It complicates deploy process. When server runs "yarn install", it loads tons of dependencies not needed for the actual build target
    – Alex Grin
    Commented Feb 12, 2020 at 16:25
  • i used the default generator from nx, and it seems its giving me a separate package json for my apps
    – noob7
    Commented Apr 3, 2023 at 7:19
5

The accepted answer is short-sighted.

Yes a single package.json is fantastic for development, it allows you to co-ordinate versions for all your dependencies and hoist them to the root. But when you want to deploy an application - you don't want to ship the dependencies for every application in your monorepo

In-fact there was an open issue about this exact problem on nx for quite some time.

Solution 2022

Now you can use the generatePackageJson option in your project.json build target options, to create a package.json for each app you wish to deploy.

Note: this is not documented, but you can read about it in the linked Issue, and merged PR.

Improve this answer
1
  • Indeed, here's the relevant PR #4164
    – icc97
    Commented Mar 19 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.