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

feat: unforce module CommonJS when testing with ESM #2199

Merged
merged 1 commit into from Dec 13, 2020
Merged

feat: unforce module CommonJS when testing with ESM #2199

merged 1 commit into from Dec 13, 2020

Conversation

ahnpnl
Copy link
Collaborator

@ahnpnl ahnpnl commented Dec 10, 2020

Summary

When extensionsToTreatAsEsm option is not an empty array, CommonJS enforcement will be no longer applicable.

Test plan

Adjusted unit tests and e2e tests, green CI

Does this PR introduce a breaking change?

  • Yes
  • No

To run tests with ESM support, one needs to make sure that:

  • module in tsconfig should be either es2015 or es2020 or esnext
  • Use ts-jest ESM presets or define value for extensionsToTreatAsEsm option properly

Other information

N.A

@ahnpnl ahnpnl added this to the ts-jest v27 milestone Dec 10, 2020
@ahnpnl ahnpnl added the 💣 Breaking Changes Includes a breaking change and should probably wait until we're preparing for the release of a major label Dec 10, 2020
@ahnpnl ahnpnl changed the title chore: remove enforcing default module CommonJS when resolving tsconfig feat: support ESM Dec 10, 2020
@coveralls
Copy link

coveralls commented Dec 11, 2020

Pull Request Test Coverage Report for Build 419102349

  • 5 of 5 (100.0%) changed or added relevant lines in 2 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.01%) to 93.631%

Totals Coverage Status
Change from base Build 418685370: 0.01%
Covered Lines: 935
Relevant Lines: 965

💛 - Coveralls

Repository owner deleted a comment from coveralls Dec 11, 2020
@ahnpnl ahnpnl changed the title feat: support ESM feat: unforce module CommonJS when testing with ESM Dec 13, 2020
When `extensionsToTreatAsEsm` option is not an empty array, `CommonJS` enforcement will be no longer applicable

BREAKING CHANGE
To run tests with ESM support, one needs to make sure that:
 - `module` in tsconfig should be either `es2015` or `es2020` or `esnext`
 - Use `ts-jest` ESM presets or define value for `extensionsToTreatAsEsm` option properly
@ahnpnl ahnpnl marked this pull request as ready for review December 13, 2020 16:59
@ahnpnl ahnpnl merged commit 64a8ea1 into kulshekhar:master Dec 13, 2020
@ahnpnl ahnpnl deleted the unforce-module-type branch December 13, 2020 18:35
Comment on lines +249 to +251
this._overriddenCompilerOptions.module = this.jestConfig.extensionsToTreatAsEsm.length
? undefined
: this.compilerModule.ModuleKind.CommonJS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think ts-jest should care about this new option. Transformers will be called with supportsStaticESM: true if import statements can be used and supportsDynamicImport: true if import expressions can be used.

Expressions can be used in both ESM and CJS, but statements only work in ESM mode. I don't think you need to look at the stuff Jest uses to figure out what mode to run, you can just look at those flags

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aw thanks for the info. Actually I was looking for a single flag to decide to unforce. With TypeScript compiler, it's not possible to transform codes with only supportsStaticESM: true or supportsDynamicImport: true.

What do you suggest because it is possible that supportsDynamicImport: false and supportsStaticESM: true or vice versa. When will all ESM options be true ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm seem like I need to configure preset manually to enable all ESM options. I thought extensionsToTreatAsEsm can automatically enable all ESM options

Copy link
Contributor

@SimenB SimenB Dec 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no single option to force either mode, as most likely CJS will always be a part of the test run (from node_modules). So it's always per file transformed. That said, it will be all .ts files for instance. But yeah, you should probably have separate compilers for CJS vs non-CJS in memory or something so you can switch between them

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, so you suggest that CJS should be compiled separately from non-CJS. Any extensions in extensionsToTreatAsEsm should be compiled with non-CJS path.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, sorta. I don't think you should look at extensionsToTreatAsEsm at all - you should look at the options that is passed to process

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will ESM options be decided only via jest config or they can be also changed by runtime ?

Copy link
Contributor

@SimenB SimenB Dec 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

runtime, as we lookup package.json to check for type field on .js files https://nodejs.org/api/esm.html#esm_enabling

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💣 Breaking Changes Includes a breaking change and should probably wait until we're preparing for the release of a major
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants