NODE_ENV=production seems to be ignored for functions bundling

Support
1

[lamda-functions doesn’t seem to be the correct topic but is the best I can find]

site: WAI-Team/ wai-authoring-tools-list

  • project is a ruby build (jekyll)
  • the unbundled Javascript function requires the module uuid
  • the package.json in the root declares this in devDependencies
  • netlify.tml declares NODE_ENV="production"
  • function deployment is set to be with @netlify/plugin-functions-install-core
  • I see the warning about production in the build log
  • is a preview deploy (ie via github integration)
  • I see the warning about production in the deploy log

Result: The function works!?!?
Expected: it fails to find uuid. I was expecting to have to move uuid to dependencies from devDependencies

The reason I set production is I use playwright for local test (eventually like to use in CI/CD). As this is a very large install I didn’t want it to be installed on Netlify deploys, slowing things down.

Q: Is what I’m doing sensible? Or are only USED modules actually installed and bundled for functions?
Q: Shouldn’t function deployments use NODE_ENV too?
Q: Ideally I’d say NODE_ENV=production for ALL Netlify builds and not local dev. Instead had to set NODE_ENV 3 times to cover all the build options.

2

I’ll start with Question 2:

Shouldn’t function deployments use NODE_ENV too?

I don’t see why functions would need to access this variable unless your code specifically depends on that. The reason to this would probably also answer the first question:

Only the modules that you actually use in the functions (and their dependencies) are bundled along with a function. We have no reason to deploy your entire node_modules directory, especially if there are 10 functions in a site, that would lead to 10 deployments of the same folder.

What exactly are you trying to achieve with this configuration? I’m not talking about setting the variable 3 times, but I was wondering why you need to do that considering development one works fine too. Are there any specific needs?

2 Likes
3

OK, yes if you tree shake the modules for deploying with the functions that does answer 1 and 2 :slight_smile:

Thinking a bit more I guess this “bundled” applies to AWS functions needing to be self contained code? And you can;t share modules between them? The docs don’t seem to explain it al all well if you don’t have any familiarity with AWS lambda.

What exactly are you trying to achieve with this configuration

Purely to keep playwright our of all deployments. Yes dev deployments have never ever been an issue before. It just made sense to keep all large dev modules out of the deployments to speed up. But if you use good global module caching that’s not an issue either. I may have been solving an imaginary problem.

2 Likes