[Feature] Option to pass --require

[blakeembrey]

Do you want to request a feature or report a bug? Feature

What is the current behavior? Does not exist.

What is the expected behavior?

It would be nice to have the possibility to pass through --require or -r, which is available in node.js and mocha. It would just do a direct require() of the content from the current working directory. This flag is regularly used for setup related things, such as -r longjohn -r source-map-support/register, and can also be used for test environment set up.

The only previous mention I've seen of this in jest is #1460, but it didn't touch on the feature itself at all.

[cpojer]

Jest has a setupFiles config which I think is enough. I think we also support --setupTestFrameworkScriptFile on the cli for this use case. Happy to accept a PR that renames this though.

[blakeembrey]

Thanks, I had overlooked it. FWIW, they have different semantics as well (doesn't follow node's require algorithm, need to manually specify the file inside the module relatively which can break if main changes).

[jdalton]

A “require” option like those in ava, mocha, nyc, tape, and even webpack (soon) are handy for loading things like custom module loaders, e.g. @babel/register or @std/esm.

I've seen folks, like @gaearon, express frustration getting setups to work and I think the -r flag may help. Related to #4842

[cpojer]

Nowadays Jest supports --setupFiles on the cli.

[SimenB]

I'd love to make sure @std/esm works in Jest. I'm not sure what would be needed though - I've never tried to use it. From https://stackoverflow.com/a/46575077/1850276 it seems just allowing some thing to intercept _execModule would be enough, but I doubt it works in practice if you also try to mock things down the tree. Haven't tested it out, though.

The problem with supporting the normal --require hook is that Jest implements require itself (for mocking and sandboxing purposes), so I doubt the normal way @std/esm registers itself would work anyways - we don't support e.g. require.extensions. But I understand that require hooks in general has its uses.

What would be needed? If we add a new requireHooks or whatever, what would that need to receive in order to be able to do it's thing? Specific use case being @std/esm.

[jdalton]

Hi @SimenB!

Thanks! Jest support is a priority for me too.

The problem with supporting the normal --require hook is that Jest implements require itself (for mocking and sandboxing purposes),

Jest's mock loader has a couple issues, but @std/esm works around them:

• require.extension is empty
• module is a plain object without a Module constructor

A lot has changed in @std/esm since that stackoverflow issue was posted, so I'd need to check things out again. With each release, the @std/esm loader relies less and less on Node's loader hooks. It simulates the entire load pipeline, complete with working require.extensions and proper module constructor too 😋

The @std/esm loader does have a scenario test for Jest. However, it's testing the scenario of projects using @std/esm being tested with Jest, but not writing tests themselves in ESM (which is the issue Dan was running into).

@cpojer

Nowadays Jest supports --setupFiles on the cli

Is @blakeembrey's comment still correct?

[SimenB]

I'd be happy to work on this if we could figure out what @std/esm would need from a potential hook (not necessarily a hook, of course). It would suck if people ended up not selecting jest because it made it harder to use esm than other testing frameworks.

[jdalton]

@SimenB Okay! I'll report back.

[TrySound]

@SimenB Don't know what is changed, but jest 22 freezes after start. jest 21 works fine.
https://github.com/TrySound/esm-jest-bug

[patrickhulce]

Has there been any progress here/could it be re-opened to track necessary work? I just transitioned from mocha and --setupFiles does not seem to support the source-map-support/register use case. I've resorted to a noop transform which is less than ideal compared to -r source-map-support/register and still doesn't work for --coverage, but at least it's something

{
  "transform": {
     ".*": "<rootDir>/source-map-support-jest.js"
  }
}

require('source-map-support/register')

module.exports = {
  process(file) {
    return file
  }
}

Better yet, is there a reason jest does not support external source maps in the first place? With all that's baked in, I somewhat expected this. asked in appropriate issue

[lukepighetti]

I am trying to wire up ts-node to Jest for breakpoints in VS Code. The existing methods use the --require / -r flag in Mocha, such as:

{
    "name": "Current TS Tests File",
    "type": "node",
    "request": "launch",
    "program": "${workspaceRoot}/node_modules/mocha/bin/_mocha",
    "args": ["-r", "ts-node/register", "${relativeFile}"],
    "cwd": "${workspaceRoot}",
    "protocol": "inspector"
}

This argument appears to match Node's require flag. I am trying to replicate this behavior in Jest and I am coming up short. Just wanted to present a use-case for --require that I have personally run into. Any suggestions for resolution are appreciated.

[SimenB]

Jest does not support running with ts-node. It should not be necessary either, see https://github.com/Microsoft/vscode-recipes/tree/master/debugging-jest-tests

[lukepighetti]

Following that guide while debugging a Typescript file (ie utils.spec.ts) will run the tests, debugger will attach (according to logs), but the breakpoint won't fire. Should I open another issue to address documentation for Typescript tests?

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.