Disabling javascript dependencies install

Hey

I need to completely disable the automatic npm install / yarn install, i have my own custom install command, and having the also the default install command takes long time.

Is there a way to achieve that?

Thanks!

Bnaya

Hi @Bnaya,

No, it’s not possible at the moment. Netlify will install all dependencies, languages and frameworks that your project might need and only then proceed to the build command.

This works fine for a lot of people, could you please explain as to what your use case is that won’t work fine with this workflow? We can file a feature request accordingly.

Hey @hrishikesh, thank you for the replay!
I have an existing codebase with some custom dependency bootstrapping strategy, that includes deleting previous node_modules + patching some of the packages.
That means that out of the box I’m “paying” for double dependencies install + caching behaviour that does not benefits me and takes a a lot of time.

What i’ve end up doing is:

[build]
  base = "trick-netlify/"
  publish = "../packages/web/build"
  command = "cd ../ && yarn bootstrap && yarn build:web"
  ignore = "exit 1"

[build.environment]
  NETLIFY_USE_YARN = "true"

Where trick-netlify contains minimal package.json that takes no time to install and to try and cache.

Controlling the deps installation & cacheing behaviour is part of any modern CI, the good ones also let you configure multiple separated caches with cache keys that are based on a hash of the lock file and other parameters.

Thanks again!

Bnaya

Hi @Bnaya,

Thank you for the response. It looks like Netlify’s build system is not suitable for your use case at the moment. While I can get this files as a feature request, we don’t know if/when this will get implemented as I’ve seen this being requested for the first time.

Meanwhile, I’d advise building elsewhere (for example GitHub Actions), and publishing to Netlify using Netlify CLI or API.

Thanks!

My workaround is working nicely, so no rush, but I definitely think it will make the product much better!

Was a ticket for this ever submitted and tracked? I have a possible workaround, but it requires some work that conflicts with other choices the team has made for code organization. I think this feature would be a good idea to have as an option.

My use-case: we share a package.json file within a mono-repo. My site doesn’t require react, next, etc. so I shouldn’t need to download those packages when I run a build. It would be excellent to have some sort of control of what actually gets installed in a shared package.json in a mono-repo. If you need further clarifications, I’d be happy to provide them. :slight_smile:

Hey @S117,

Your request seems to be a bit different than @Bnaya’s. They wanted to skip installing Node Modules altogether, as they wanted to install it themselves.

You want to install Node Modules, just not all of those. Are you going to be handling installing these modules yourself? I don’t see why you cannot benefit from build cache - which skips install Node Modules as long as the package.json doesn’t change.

1 Like

Hey @hrishikesh! Yeah, my request is a bit different but similar in thought. While cacheing helps, it is not useful to download and upload 818MB cache on every deploy. Currently this process combined costs 30 seconds or so to do per deploy. The easiest way would be to separate out the projects to read from their own package.json however, we currently don’t have plans to make that change for many reasons. We have implemented NX improvements which should help and reduce this, but I’m not 100% confident until the code merges and we see the results live.

Overall, it’s not a huge deal due to current minutes allotment + other optimizations we have done, but it still seems wasteful in server time to run the download and reupload of the cache every time, especially when the cache is sharing deps the site doesn’t actually need.

Again, easiest and best way would be for my side to just split out package.json files into their own area. However, our monorepo structure needs to work to achieve that properly if we choose to do that.

Thanks for the feedback. We’ll pass this information in the previous ticket.