Default NODE_ENV to "development" if it's undefined when starting jobs worker (#11572)

This mimics the behavior of `yarn rw dev` where `NODE_ENV` will equal
`development` if you don't set it explicitly.

Because of this, you need to make sure you explicitly set it in other
environments. You should set `NODE_ENV=production` in your `.env`
file/Dockerfile on your production server, for example. The docs have
been updated to note this.

Closes #11569

Author: cannikin

.changesets/11572.md

@@ -0,0 +1,3 @@
+- Default NODE_ENV to "development" if it's `undefined` when starting jobs worker (#11572) by @cannikin
+
+This mimics the behavior of `yarn rw dev` where `NODE_ENV` will equal `development` if you don't set it explicitly.

docs/docs/background-jobs.md

@@ -701,7 +701,7 @@ By checking the `lastError` field in the database you can see what the last erro
 
 ## Deployment
 
-For many use cases you may simply be able to rely on the job runner to start your job workers, which will run forever:
+For many use cases you may be able to rely on the job runner to start and detach your job workers, which will then run forever:
 
 ```bash
 yarn rw jobs start
@@ -723,6 +723,20 @@ Of course if you have a process monitor system watching your workers you'll want
 
 :::
 
+### NODE_ENV
+
+You'll need to explicitly set your `NODE_ENV` when in environments other than development or test. We like having a `.env` file in a serverfull production environment, and you just include:
+
+```bash
+NODE_ENV=production
+```
+
+If you're using Docker, make sure you have an `ENV` declaration for it:
+
+```docker
+ENV NODE_ENV="production"
+```
+
 ## Advanced Job Workers
 
 As noted above, although the workers are started and detached using the `yarn rw jobs start` command, there is nothing to monitor those workers to make sure they keep running. To do that, you'll want to start the workers yourself (or have your process monitor start them) using command line flags.

docs/versioned_docs/version-8.0/background-jobs.md

@@ -705,7 +705,7 @@ By checking the `lastError` field in the database you can see what the last erro
 
 ## Deployment
 
-For many use cases you may simply be able to rely on the job runner to start your job workers, which will run forever:
+For many use cases you may be able to rely on the job runner to start and detach your job workers, which will then run forever:
 
 ```bash
 yarn rw jobs start
@@ -727,6 +727,20 @@ Of course if you have a process monitor system watching your workers you'll want
 
 :::
 
+### NODE_ENV
+
+You'll need to explicitly set your `NODE_ENV` when in environments other than development or test. We like having a `.env` file in a serverfull production environment, and you just include:
+
+```bash
+NODE_ENV=production
+```
+
+If you're using Docker, make sure you have an `ENV` declaration for it:
+
+```docker
+ENV NODE_ENV="production"
+```
+
 ## Advanced Job Workers
 
 As noted above, although the workers are started and detached using the `yarn rw jobs start` command, there is nothing to monitor those workers to make sure they keep running. To do that, you'll want to start the workers yourself (or have your process monitor start them) using command line flags.

docs/versioned_docs/version-8.1/background-jobs.md

@@ -701,7 +701,7 @@ By checking the `lastError` field in the database you can see what the last erro
 
 ## Deployment
 
-For many use cases you may simply be able to rely on the job runner to start your job workers, which will run forever:
+For many use cases you may be able to rely on the job runner to start and detach your job workers, which will then run forever:
 
 ```bash
 yarn rw jobs start
@@ -723,6 +723,20 @@ Of course if you have a process monitor system watching your workers you'll want
 
 :::
 
+### NODE_ENV
+
+You'll need to explicitly set your `NODE_ENV` when in environments other than development or test. We like having a `.env` file in a serverfull production environment, and you just include:
+
+```bash
+NODE_ENV=production
+```
+
+If you're using Docker, make sure you have an `ENV` declaration for it:
+
+```docker
+ENV NODE_ENV=production
+```
+
 ## Advanced Job Workers
 
 As noted above, although the workers are started and detached using the `yarn rw jobs start` command, there is nothing to monitor those workers to make sure they keep running. To do that, you'll want to start the workers yourself (or have your process monitor start them) using command line flags.

packages/jobs/src/__tests__/setupEnv.test.ts

@@ -0,0 +1,29 @@
+import { describe, expect, it, vi, afterEach } from 'vitest'
+
+import { setupEnv } from '../setupEnv'
+
+vi.mock('@redwoodjs/cli-helpers/loadEnvFiles', () => {
+  return {
+    loadEnvFiles: () => {},
+  }
+})
+
+const ORIGNAL_NODE_ENV = process.env.NODE_ENV
+
+describe('setupEnv', () => {
+  afterEach(() => {
+    process.env.NODE_ENV = ORIGNAL_NODE_ENV
+  })
+
+  it('if not called, NODE_ENV is not overridden in any way', () => {
+    expect(process.env.NODE_ENV).toEqual(ORIGNAL_NODE_ENV)
+  })
+
+  it('sets NODE_ENV to development if it starts undefined', () => {
+    delete process.env.NODE_ENV
+
+    setupEnv()
+
+    expect(process.env.NODE_ENV).toEqual('development')
+  })
+})

packages/jobs/src/bins/rw-jobs-worker.ts

@@ -8,14 +8,13 @@ import process from 'node:process'
 import { hideBin } from 'yargs/helpers'
 import yargs from 'yargs/yargs'
 
-import { loadEnvFiles } from '@redwoodjs/cli-helpers/loadEnvFiles'
-
 import { PROCESS_TITLE_PREFIX } from '../consts.js'
 import type { Worker } from '../core/Worker.js'
 import { WorkerConfigIndexNotFoundError } from '../errors.js'
 import { loadJobsManager } from '../loaders.js'
+import { setupEnv } from '../setupEnv.js'
 
-loadEnvFiles()
+setupEnv()
 
 const parseArgs = (argv: string[]) => {
   return yargs(hideBin(argv))

packages/jobs/src/bins/rw-jobs.ts

@@ -13,10 +13,9 @@ import { setTimeout } from 'node:timers'
 import { hideBin } from 'yargs/helpers'
 import yargs from 'yargs/yargs'
 
-import { loadEnvFiles } from '@redwoodjs/cli-helpers/loadEnvFiles'
-
 import { DEFAULT_LOGGER, PROCESS_TITLE_PREFIX } from '../consts.js'
 import { loadJobsManager } from '../loaders.js'
+import { setupEnv } from '../setupEnv.js'
 import type {
   Adapters,
   BasicLogger,
@@ -26,7 +25,7 @@ import type {
 
 export type NumWorkersConfig = [number, number][]
 
-loadEnvFiles()
+setupEnv()
 
 process.title = 'rw-jobs'
 

packages/jobs/src/setupEnv.ts

@@ -0,0 +1,11 @@
+import { loadEnvFiles } from '@redwoodjs/cli-helpers/loadEnvFiles'
+
+export const setupEnv = () => {
+  loadEnvFiles()
+
+  // If even after loading `.env` we find that `NODE_ENV` is `undefined` default
+  // to `development` to mimic what the other CLI tools to
+  if (process.env.NODE_ENV === undefined) {
+    process.env.NODE_ENV = 'development'
+  }
+}