feat: add removeJsExtension to pathsToModuleNameMapper

[jjangga0214]

Summary

ESM requires imported file's extension (e.g. import foo from './foo.js' instead of import foo from './foo').

This is also true for typescript modules. They should be imported as .js, not .ts.

But jest does not have an "automatic typescript import extension mismatch detection for ESM". Rather, it lets users configure moduleNameMapper by themselves.

Currently, pathsToModuleNameMapper does not support this.

Thus, a new option removeJsExtension is added.

This is not a breaking change.

Test plan

Test code is provided as well.

Does this PR introduce a breaking change?

• Yes
• No

Other information

Thanks for maintaining ts-jest :)

[ahnpnl]

Would you please configure and add tests to https://github.com/kulshekhar/ts-jest/tree/main/e2e/native-esm-ts and https://github.com/kulshekhar/ts-jest/tree/main/e2e/native-esm-js as well?

[coveralls]

Pull Request Test Coverage Report for Build 2987031218

• 0 of 8 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.5%) to 96.366%

---

Totals
Change from base Build 2984265392:	0.5%
Covered Lines:	4007
Relevant Lines:	4104

---

💛 - Coveralls

[coveralls]

Pull Request Test Coverage Report for Build 3122453706

• 13 of 13 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.5%) to 96.21%

---

Totals
Change from base Build 3122330070:	0.5%
Covered Lines:	4046
Relevant Lines:	4149

---

💛 - Coveralls

[jjangga0214]

@ahnpnl Well, I want to ask your(and others) opinion(s).

• I don't understand how a new test should be added to e2e/native-esm-js. Would it use typescript's paths mapping even though it's entirely a javascript project?
• To use pathsToModuleNameMapper in e2e/native-esm-ts's jest config, there're two different ways.
  • Only test native-esm-ts after building the ts-jest project. That's to import pathsToModuleNameMapper from the built js file.
  • Let jest config be a typescript file, to test without building first. This requires
    • Install ts-node
    • Rename jest-isolated.config.js to .ts.
    • Create jest.config.ts (non-isolated) and remove jest config from package.json
    • Let the configs use import { pathsToModuleNameMapper } from '../../src/config'.
    • Configure tsconfig.json to let ts-node read jest configs as cjs.

Though I 100% respect the intention for thorough test, I doubt if it's really worth the effort in this case.
pathsToModuleNameMapper is a pure function without state as a side effect, which means unit test is enough, in my very humble opinion.

How do you think?
Thanks :)

[ahnpnl]

@ahnpnl Well, I want to ask your(and others) opinion(s).

• I don't understand how a new test should be added to e2e/native-esm-js. Would it use typescript's paths mapping even though it's entirely a javascript project?

I think we can skip this one

• To use pathsToModuleNameMapper in e2e/native-esm-ts's jest config, there're two different ways.

  • Only test native-esm-ts after building the ts-jest project. That's to import pathsToModuleNameMapper from the built js file.

This is the current way how e2e test works. When running npm run test, first source codes will be built and in

ts-jest/e2e/native-esm-ts/package.json

Line 10 in 912a3d1

"^.+\\.m?tsx?$": ["<rootDir>/../../legacy.js", {

we reference the usage from build folder. This is the prefer way.

For your case, it would be something like

// jest.config.js
import { pathsToModuleNameMapper } from '<path_to_index_file_in_build_folder>'

• Let jest config be a typescript file, to test without building first. This requires

  • Install ts-node
  • Rename jest-isolated.config.js to .ts.
  • Create jest.config.ts (non-isolated) and remove jest config from package.json
  • Let the configs use import { pathsToModuleNameMapper } from '../../src/config'.
  • Configure tsconfig.json to let ts-node read jest configs as cjs.

This way we shouldn't do.

Though I 100% respect the intention for thorough test, I doubt if it's really worth the effort in this case. pathsToModuleNameMapper is a pure function without state as a side effect, which means unit test is enough, in my very humble opinion.

How do you think? Thanks :)

Even though this is a pure function but it still can break stuffs which unit tests can't capture. We try to put everything into e2e tests after unit tests to always have more confidence.

[jjangga0214]

@ahnpnl Thanks for the comment. Would you check the new commits?