If you’re bundling code, you’re doing development work, and you’d have devDependencies installed:

For a library, once you’ve shipped your code, someone using it wouldn’t need your bundler/testing libraries/dependency types/compilers/etc installed, so they wouldn’t install your devDependencies.

For an application, if you’re building it on the server, you’re probably doing it wrong, but in that case you would want to install devDependencies. If you’ve built it locally or in a pipeline and you’re running it on the server from your artifact, then you probably don’t need devDependencies, as those are only useful during dev and build.

I think it makes more sense if you think about backend applications: If you write a Webserver with ExpressJS in typescript, you need typescript only to compile it (dev dependency) but once compiled, you only need ExpressJS in your node_modules for the app to be able to run ("regular" dependency).

Frontend development is a bit strange in that respect, because often everything gets bundled into your dist/ directory, so technically there are no runtime dependencies? In that case it's more of a hint to let you know "this goes into the bundle" vs. "this is part of the compiler toolchain"

You only need to worry about devDependencies vs dependencies if you are going to publish the project you are working on as an npm package. If you are making a webapp or something else that you will run, then it doesn't matter.

Are you using Node.js on the backend, or are you just using JS for the frontend?

In frontend JS, everything should be a dev dependency. At runtime, you only use the JS bundles generated by your bundler, which is a build-time process. That means you don't actually directly use Node modules at runtime, just the bundled versions, so there should not be any non-dev dependencies.

For backend JS, anything only used in dev (unit testing, mocking, bundlers, etc) should be a dev dependency, and stuff you need at runtime (like Express, etc) should be a regular dependency.

Deployment is part of dev, so no, we don't typically use --omit=dev or --only=prod in the deployment pipeline.

It is usual (and actually pretty important) to have --omit=dev or --only=prod in the test pipeline.

This often means we do need separate build environments in CICD for test and for deployment.

Specifically, what is important is that some part of the CICD process will fail if a production dependency is missing. Normally, that's the unit test run, supported by a --omit=dev or --only=prod flag to be sure that no upstream dev dependency causes a false success.

This outcome can be achieved in various other ways, but is usually achieved by separating the test and deployment environments.

Edit: to cloud matters further, there's plenty of cases where not bothering with --omit=dev or --only=prod during test run is fine. So you will still see healthy well run projects that do not separate test from deploy, and that's not necessarily a mistake.

But the best practice is a best practice for good reasons, so naturally we stick with it when unsure.