anyone know how to bundle dependencies when building a nestjs app so that I do not need to yarn install in the docker container when deploying? It seems that when I have a default webpack config (no externals) that is supposed to do it but when i run the server it cannot find
module 'tslib' , I am currently using the nest cli to build it because for some reason our CI errors out if i try to use nx as it fires up over 20 workers then runs out of memory.
I thought I tried this, and it worked when doing some POC. Build with the prod flag. Copy the dist folder for the app to some other location then open a terminal in the folder with the index.js (or whatever the entry file is) and run node index.js
Ya that seemed to work for me when I did it on my machine but as soon as I copied the bundle to the docker image and ran it (based off of node11 alpine) it fails with not finding tslib
Ah, you are switching target environments, I don’t know the answer other node apps I have built to be published I have put a package.json in the bundle and let the build server install in the target framework, these were not nx apps. I am very interested in the outcome of this.
Ya it is odd, I am also not using nx for the nestjs build proces (the nest cli instead) so there isn’t really any nx specific stuff here. More a general building/bundling question
I was hoping web pack would just take care of it for us.
It is supposed to by default. From what i read in the docs anyway
Can you update this thread if you figure it out?
Following this :+1:
Haven’t tried it yet, but setting importHelpers to false in the tsconfig.json might do it, when set to true it will use tslib to reduce the bundle size (which honestly is not a huge issue when deploying a server I don’t think)
That got rid of the tslib error but now it cannot find
@nestjs/core so deps are definitely not being packaged.
Was this created by nx or was it imported?
it was initially migrated over from a standalone repo
then i had to add a custom webpack config and use the nest cli to build
(had the same issue with building via nx though)
Hmmmm…. I will say I haven’t had much with building and deploying node apps with nx beyond a quick poc, but this seems like it should be core functionality.
And it supposedly is for webpack because you have to explicitly define externals that are not to be bundled
I realize you aren’t building with nx, so sorry if this isn’t useful/something you already know, but nx has
externalDependencies to control this. IIRC, it used to default to
none and now it defaults to
all. The issue in the
none days was that the way some node libs lazily require peer dependencies didn’t work well with webpack, so you had to manually define the list of dependencies that you weren’t actually using and treat them as external. I’ve just stuck with
all, but it would be great to build everything into a single main.js painlessly.
I added: “externalDependencies”: ”all” to my architect\build\options, but I get Error: Cannot find module ‘tslib’ when running node against my bundled main.js file
externalDependencies: "all" is telling Nx not to bundle any dependencies into the main.js, and that you’ll take care of those yourself (most likely via having a populated
node_modules folder on your server)
gotcha! I had that reversed. thanks
I will give it a shot building with Nx with external dependencies
i wonder why it does not work with webpack though…
isn’t that like webpacks thing…
Have you checked with the folks at discord/nestjs official channel. They have one for devops.
No not yet.
using external dependencies “all” did not work. Also all is supposed to be default.
Did you try none?
yeah, “all” wouldn’t cause Nx to bundle in your dependencies (and is now the default) - “none” would, but can cause other issues
I think the confusion of external dependencies is that it a question asking what packages will be external and not bundled with the build
oh so externalDepedencies: all means don’t bundle all, but externalDeps: none means don’t not bundle all?
“all” means “all of my dependencies are external”
Hahah complete opposite of how my brain interpreted it.
it’s extremely confusing
Ok it ran out of memory while building this time, so that means it definitely is bundling everything now.
no problem! i mentioned this somewhere in this thread, but the issue with “none”, at least last time i tried it, is that some node packages lazy load things in a way that isn’t compatible with webpack
Ah ok well I will give it a shot and see what happens, thank you very much.
so you have to actually use the third option there, which is specifying a list of those lazy loaded modules that you don’t use (so webpack thinks they’re external and doesn’t try to bundle them)
good luck! it’s been a while since i’ve tried it, but i’d love to have the single bundle file, too. let us know how it goes!
I will update this thread once I know more!
I also found out i can pass in worker and memory limits through the angular.json so I can now build with nx instead of the nest cli
if the option isn’t getting passed through for some reason, you might have luck with
node --max-old-space-size=8192 node_modules/.bin/nx build your-project
It seems as though the maxWorkers was working correctly but always said using 2048 in mem (even though i had it set to 1024), I also had
node --max_old_space_size=4096 ./node_modules/.bin/nx build core as the build command already as well.
Wanted to report back after I did some more reading. Here is a comment on a github issue about bundle deps with a nest app from Kamil (the created of Nest). Veri informative.
- what was your take away on how to do this in an nx repo?
Wow this was months ago now! I still have my WIP PR open so pulling it up shows that I had to set
--max_old_space_size=4096 when running nx build (otherwise it errors) and then in the (angular|workspace).json
Needs to be set (I think), I believe I left this in working condition but I remember I ran into some hiccups and just figured it was easier to yarn isntall the deps after it was build, slows down the CI a bit and a bit annoying to manage another package.json just for the server but the headache is acceptable to me right now. Hope that helps
Thanks, I will give it a shot
Is there a PR or a Feature Request in NX to make this more of a standard?
- This looks like a good solution hope the functionality gets built in https://github.com/nrwl/nx/issues/1518#issuecomment-533555445
Maybe not seems like you have to maintain all your implicit dependencies manually