[]previous and next page

NODE_ENV

NODE_ENV is set by the command, never by a file, and a value in the shell wins over the command:

For agentsUpdated

NODE_ENV is set by the command, never by a file, and a value in the shell wins over the command:

  • dusk dev (Vite's dev server): development, unless the shell already sets NODE_ENV.
  • dusk build: production, unless the shell already sets NODE_ENV.
  • dusk start runs the built server, which is created with dev: false, so it is production whatever NODE_ENV says.
  • createHandler without a dev option treats NODE_ENV=production as production (and then requires security.allowedHosts). The generated server entries always pass dev, so only code that calls createHandler itself is affected.

A .env, .env.local, .env.[mode] or .env.public file never sets NODE_ENV: Dusk never copies that name from a file into process.env, so a file cannot change the mode of the server or of the build.

The shell value is not only the server's. The client build defines process.env.NODE_ENV as the value the shell has, so NODE_ENV=development dusk build ships a development bundle of the React-style libraries. Set it per command, and never in a shared env file or in CI settings that other commands also use.