Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to test a project using pirates #6034

Closed
eventualbuddha opened this issue Apr 19, 2018 · 8 comments
Closed

Unable to test a project using pirates #6034

eventualbuddha opened this issue Apr 19, 2018 · 8 comments
Labels

Comments

@eventualbuddha
Copy link
Contributor

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

Bug

What is the current behavior?

When running jest on a project that uses pirates to customize the loading of modules, jest interferes with the operation of pirates, seeming to prevent it from working correctly. For example, when trying to load code written using ES modules using babel to transpile them, it works just fine when running the tests with mocha.

If the current behavior is a bug, please provide the steps to reproduce and
either a repl.it demo through https://repl.it/languages/jest or a minimal
repository on GitHub that we can yarn install and yarn test.

This isn't a minimal example, but cloning https://github.com/square/babel-codemod and checking out the jest branch, running yarn install and yarn test will illustrate the problem.

What is the expected behavior?

Jest should not interfere with other systems–like pirates–that hook into module loading.

Please provide your exact Jest configuration

module.exports = {
  automock: false,
  transform: {
    '^.+\\.tsx?$': 'ts-jest'
  },
  testRegex: '(/__tests__/.*|(\\.|/)(test|spec)|.*(Test|Spec))\\.(jsx?|tsx?)$',
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node']
};

Run npx envinfo --preset jest in your project directory and paste the
results here

  System:
    OS: macOS High Sierra 10.13.3
    CPU: x64 Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
  Binaries:
    Node: 9.11.1 - /usr/local/bin/node
    Yarn: 1.6.0 - /usr/local/bin/yarn
    npm: 5.6.0 - /usr/local/bin/npm
  npmPackages:
    @types/jest: ^22.2.3 => 22.2.3
    jest: ^22.4.3 => 22.4.3
@SimenB
Copy link
Member

SimenB commented Apr 19, 2018

Yeah, we don't really support require hooks at all, as we implement require ourselves. This is basically the same request as in #4842. In general we say "use transform instead", and only hook up stuff like pirates in entrypoints of your application that is not loaded by Jest.

Jest should not interfere with other systems–like pirates–that hook into module loading.

That probably won't happen, but it might be possible to play a bit nicer with modules like it, or at least detect it and throw a useful error.

@eventualbuddha
Copy link
Contributor Author

eventualbuddha commented Apr 19, 2018

This is pretty much the response I expected. I figured I’d file this as a vote in favor of a more standard config. I really like Jest’s workflow, but things like this worry me.

Perhaps a mode that uses the native require but doesn’t support mocking would work? I don’t know if the mocking is the only reason that jest has its own require system.

@SimenB
Copy link
Member

SimenB commented Apr 19, 2018

It would break out of the sandbox as well, but that might be an acceptable trade-off for you

@Hypnosphi
Copy link

In general we say "use transform instead"

Is there any way to add transforms from test runtime, without changing the config?

@SimenB
Copy link
Member

SimenB commented Sep 5, 2019

No, transforms runs outside of the test sandbox, and are setup before the sandbox is even created (shared between tests).

Jest itself uses pirates and the way we test it is via integration tests that spawn up a full version of jest and assert on the output. Maybe you can do something similar?

@github-actions
Copy link

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Feb 25, 2022
@github-actions
Copy link

This issue was closed because it has been stalled for 7 days with no activity. Please open a new issue if the issue is still relevant, linking to this one.

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 29, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants