Nx monorepos in deployment ?

[Houssem-Esprit]

Hello, currently I adopt Nx monorepos to hold my 3 apps, it was fascinating how Nx can be a great solution for a modern development approach, to deal with multiple apps and libs. When it came to the deployment phase (AWS Amplify) the cost takes the seat of judgment, Since Nx designed to store all the workspace dependencies in one place to keep track of versioning and reusability, it made the deployment more expensive on build time due to the number of dependencies of all workspace that should be installed before one app get to build.
Can anybody suggest me the best approach to get the most of Nx features with less cost in terms of bundle size and build time on deployment?

[MBollig]

I have a similar problem that has been bothering me for a long time.
We are planning an application that consists of a backend (nestjs) and a client (angular).
The backend is supposed to run on an embedded device, where the resources are limited.

The files needed for the deployment of the backend can now be generated as follows:

ng build myBackendApp --configuration=production

or

nx build myBackendApp --configuration=production

The created files from the dist directory of the backend app are now copied to the embedded device, on which node is installed.
But how can I now install on the embedded device only the dependencies that are needed to run the backend application?

Often it is recommended to copy the file package.json of the nx workspace as well and then just run node install.

However, this file contains the dependencies of all apps from the nx workspace.
In our case, those of the backend and those of the client.

The worst part is that you can't even track which application needs which dependencies anymore, because the package.json doesn't contain that information.
Because of this problem, the embedded device is cluttered with files that are only needed for the client.

What is actually needed is a way to generate a package.json file that only contains the (production) dependencies of the nestjs backend app.

Actually I assumed that this is exactly the task of the nx framework and would be generated by the command
nx build myBackendApp --configuration=production.

Did I miss something or is this important feature not supported?

Unfortunately, this would be an exclusion criterion for our project.

[lavigneer]

There's a flag you can set with the node builder to have it generate a package.json for your specific application: https://nx.dev/latest/react/node/build#generatepackagejson

I haven't used it myself since I'm working with an older version of NX at the moment, but it might help your case.

[MBollig]

Thanks Eric, that was exactly the information I was looking for.
You really saved my day.
I hope the info will also help Houssem-Esprit.

[Houssem-Esprit]

@lavigneer like @MBollig said that's exactly what I'm looking for, At the same time I'm a little bit confused since this flag generatePackageJson belongs to @nrwl/node plugin and @nrwl/node:build executor which supports only the express & Next frameworks based on the docs. In my case, I'm dealing with a bunch of Angular & Ionic apps whose default executor is @angular-devkit/build-angular:browser, I hope I didn't mess up the idea but In my case, this flag didn't work with my Angular apps with the default configuration.
This is confusing since the flag worked well with @MBollig on a workspace of Nest js and Angular apps, any idea ??

[lavigneer]

@Houssem-Esprit it sounds like you may be looking for something different from @MBollig. After re-reading your initial question, it sounds like you're trying to only install a subset of dependencies required to initially build a specific application and not so much trying to limit the dependencies that need to be installed after it's built and deployed as some backend service? So you're concerned with time it takes to npm install the workspace to start building from within AWS Amplify?

I'm not familiar with AWS Amplify, but if there's some cache persistence capabilities it gives you, you could explore caching the node_modules between builds, or using something like pnpm to boost performance and keep the pnpm store cached.