Tests not runnable on running `npm run test` ( NODE_ENV not recognized)

[Jatin24062005]

p5.js version

No response

What is your operating system?

None

Web browser and version

No response

Actual Behavior

The test and test:watch scripts in package.json use NODE_ENV=test jest directly. This syntax works on macOS/Linux shells but fails on Windows (CMD, PowerShell, Git Bash). As a result, tests cannot be executed on Windows machines.

• On Windows, running:

  npm run test

  produces:

  'NODE_ENV' is not recognized as an internal or external command,
  operable program or batch file.
  

• This makes tests not runnable on Windows environments.

Expected Behavior

• Running:

  npm run test

  should start Jest with NODE_ENV=test set correctly.
• Tests should run successfully across all operating systems.

Steps to reproduce

Steps:

1.Clone the repo on a Windows machine.
2. Run npm install
3.Run npm run test

Snippet:

// Paste your code here :)

[Jatin24062005]

Update the test scripts in package.json to use cross-env, which is already used in other scripts:
"scripts": { "test": "cross-env NODE_ENV=test jest", "test:watch": "cross-env NODE_ENV=test jest --watch" } if this sounds good can i open a PR?

[Jatin24062005]

@raclim After fixing the missing cross-env in the npm scripts locally, I was able to run npm run test.

However, the test suite still fails on a fresh setup due to the MongoMemoryServer binary download timing out during the server/models/__test__/user.test.ts tests.

It seems the MongoDB binary (~600MB) needs to be downloaded the first time, which causes Jest to exceed the default timeout.

Example error:
"Exceeded timeout of 30000 ms for a hook."

This may require either:

• increasing the Jest timeout for this test, or
• caching / adjusting the MongoMemoryServer configuration.

Let me know if this should be handled in a separate issue.

[saurabh24thakur]

I can confirm this is happening on Windows 11 too. Switching to cross-env is definitely the right move here since it’s already used in other parts of the project and is pretty much the standard for fixing these OS-specific script errors.

As for the MongoMemoryServer timeout, maybe we could increase the testTimeout specifically in the user.test.ts file rather than making a global change? That way, people on slower connections won’t get stuck on the first run while the 600MB binary downloads, but we don't slow down the rest of the test suite...