Test runner module mocking format
Spun off from https://github.com/nodejs/node/pull/53619#issuecomment-2196867153; I wanted to start a new issue for this as it’s arguably a separate issue from unflagging
--experimental-detect-module
. cc@cjihrig
@nodejs/test_runner
Regarding the module mocking - the mock loader (
lib/test/mock_loader.js
) uses that information to determine whether to generate source code in CJS or ESM. I think there are a few options to fix it:
- Maybe it doesn't really matter and it can be removed?
- Pick a default when the hint is undefined.
- Make it an option that the user can provide as input.
It seems like @cjihrig
above is referring to this? https://nodejs.org/docs/latest/api/test.html#mockmodulespecifier-options. Which seems to be implemented here? https://github.com/nodejs/node/blob/02bd8662985a2c4e11f3235f3fc5bb28b801c3c4/lib/internal/test_runner/mock/mock.js#L489-L516
Per the docs, mock.module
supports defining mocks for both module systems based on passed-in objects (not source code). Then we generate source code here? https://github.com/nodejs/node/blob/02bd8662985a2c4e11f3235f3fc5bb28b801c3c4/lib/test/mock_loader.js#L163-L175
At first I was confused as to how this works, since ESM is unlike CommonJS in that ESM can have a default export that’s something other than an object whose properties are the named exports; so how can this one API generate mocks that apply to both module systems while still supporting this ESM-only feature. But then I noticed that an exception gets thrown if the mock is created with both defaultExport
and namedExports
defined and the module is required. So I guess really it supports both module systems only if you give it input that can be consumed by both systems.
But maybe that’s the answer: if the user defines one of defaultExport
or namedExports
, it creates the source as CommonJS, and either maps the provided defaultExport
to module.exports
or it adds each of the namedExports
onto module.exports
. If the user defines both defaultExport
and namedExports
, the mock is created as ESM and the restrictions mentioned in the docs apply.
Alternatively the mock could always be created as ESM, though then you have the issue that for it to be require
-able --experimental-require-module
needs to be enabled. But maybe that behavior could be opted into by using this API. Since the user is passing in an object I assume we don’t need to worry about top-level await
.
Or we could just ask the user what format to generate the source code in. We kind of already are, though the users probably don’t realize it, since we ask for the URL of the module to be mocked and base the format on that. Though it seems like you’re trying to keep this as simple as possible so if there’s a way to avoid adding another option, I assume you’d prefer to determine this implicitly. I think determining format based on defaultExport
/ namedExports
is a better source to use rather than how the file URL resolves.