Add a way to get the enabled conditions #55824

What is the problem this feature will solve?

Currently there is no way to get the enabled conditions easily. It requires checking process.env.NODE_OPTIONS and process.execArgv which is not robust. It should be noted that although it is an edge case, the process.env.NODE_OPTIONS check should be done before any code that modifies that variable.

Some concrete cases:

1. Give custom resolvers to imitate Node.js's resolution (this one can be solved if parent parameter of import.meta.resolve is out of experimental, but I guess exposing conditions is less controversial than graduating that API from experimental)
   • Vite throws an friendly error when an optional dependency is not installed. To do that, Vite wants to check if a package is installed without using require or import so it uses the custom resolver. If Vite uses require or import, the resolve result is gets cached and requires the program to be restarted.
   • Vite bundles the config to detect the files used for the config to restart Vite when those files are modified. When bundling the config, Vite rewrites the specifies to absolute path so that it points the same path before the bundling.
   • yarn seems to parse them on their own: https://github.com/yarnpkg/berry/blob/f59bbf9f3828865c14b06a3e5cc3ae284a0db78d/packages/yarnpkg-pnp/sources/loader/makeApi.ts#L199
   • ts-node seems to parse them on their own: https://github.com/TypeStrong/ts-node/blob/ddb05ef23be92a90c3ecac5a0220435c65ebbd2a/dist-raw/node-internal-modules-cjs-helpers.js#L15
2. Let frameworks to show a warning when the user didn't set required / expected conditions.
   • For example, if frameworks expect users to set custom conditions, to show a warning they have to parse the conditions to do that for now.

What is the feature you are proposing to solve the problem?

Add conditions variable in node:module.

Example code:

// node -C development ./foo.mjs
import { conditions } from 'node:module';
console.log(conditions) // ['development']

I didn't add node to conditions in the example above, but maybe it makes sense to add that too.
But for import and require, I'm not sure if those should be added in that case. Probably the option would be to add both or neither.

What alternatives have you considered?

• Exposing getOptionValue ([Feature] Expose getOptionValue via process.getOptionValue #36935): this one got stale because it is difficult to make the API stable.