TS imports with .js extension break Jest-resolve

[dpogue]

Issue :

TypeScript files using web-compatible ES6 imports cause Jest to throw an error about not being able to find the module. This error comes from jest-resolve/build/index.js:229 and happens regardless of the module type specified in ts-jest (commonjs, amd, ES6, etc.)

Expected behavior :

TypeScript supports adding a .js extension to import statements for web-compatibility (since imports require a full path, including the extension).

I would expect ts-jest to allow TypeScript to handle this and convert it to commonjs before it gets passed to jest.

Minimal repo :

/* user.ts */
export class User {
  public name : string;

  constructor(name : string) {
    this.name = name;
  }
}

/* user.spec.ts */
import { User } from './user.js';

describe('User', function() {
});

[gabrielbrieva]

I facing the same issue :(
The problem it is the jest-resolve is managed by jest :(

Maybe we must to create a custom resolver for jest as workaround to solve this issue.

[dpogue]

I set up a custom resolver and just published it to npm: jest-ts-webcompat-resolver

[dmnsgn]

@kulshekhar this has been closed for awhile but the issue still happen in ts-jest 26.5.4.

Since handling ".js" extensions in import statement is standard in TypeScript (and will become increasingly needed as Node.js moves towards ES modules), shouldn't ts-jest resolve this correctly without the need for @dpogue custom resolver?

[ahnpnl]

Which error do you get, TypeScript type checking or Jest runtime errors? ts-jest transforms ts to js and throws type checking errors but not runtime errors.

I have modified a bit the e2e test https://github.com/ahnpnl/ts-jest/blob/test-test/e2e/__cases__/allow-js/bar.spec.ts and CI still passes https://github.com/ahnpnl/ts-jest/runs/2155197218?check_suite_focus=true (Run tests with coverage)

[dmnsgn]

A jest-resolve error:

 FAIL  test/index.spec.js
  ● Test suite failed to run

    Cannot find module './types.js' from 'src/index.ts'

    Require stack:
      src/index.ts
      test/index.spec.js

    > 1 | import { MyType } from "./types.js";
        | ^
      2 | 

      at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:306:11)
      at Object.<anonymous> (src/index.ts:1:1)

importing ./types.js (./src/types.ts file exporting some types/enums declarations) from ./src/index.ts.

[ahnpnl]

This is Jest runtime error, not ts-jest type checking error. There are a few things to check:

• Make sure the file has module.exports
• Make sure allowJs is true.
• Make sure jest config transform value specifying js processed by ts-jest

When transforming ts to js, the code from "./types.js"; becomes require(“./types.js”), which is a valid syntax. However, Jest resolver doesn’t understand, probably because missing module.exports

[dmnsgn]

Thanks for the pointers!

"./types" doesn't have module.exports as it is a full ES modules codebase (allowJs is true and the transform is "^.+\\.(t|j)s$": "ts-jest" so no problem here).

Using on "jest-ts-webcompat-resolver", it rewrites './types.js' to './types.ts' so I guess that's enough for jest-resolve to understand where to look (although it still seems a bit hacky).

[VitorLuizC]

I set up a custom resolver and just published it to npm: jest-ts-webcompat-resolver

Won't work for TSX files, but changing a bit the code to also tries resolving path replacing .js to .tsx seems to work fine.

function getResolver() {
  try {
    return require('jest-resolve/build/defaultResolver').default;
  } catch (_) {
    return require('jest-resolve/build/default_resolver').default;
  }
}

const JAVASCRIPT_EXTENSION = /\.js$/i;

function resolverTSAndTSX(path, options) {
  const resolver = options.defaultResolver || getResolver();

  try {
    return resolver(path, options);
  } catch (error) {
    if (!JAVASCRIPT_EXTENSION.test(path)) throw error;

    try {
      return resolver(path.replace(JAVASCRIPT_EXTENSION, '.ts'), options);
    } catch (_) {
      return resolver(path.replace(JAVASCRIPT_EXTENSION, '.tsx'), options);
    }
  }
}

module.exports = resolverTSAndTSX;

I'll made a PR tomorrow, but this should be included in ts-jest for sure.

EDIT: I've create a package to resolve imports same way TS does with import paths that has ".js" extension.
https://github.com/VitorLuizC/ts-jest-resolver

[ahnpnl]

custom resolver doesn't belong to ts-jest. ts-jest is just a Jest transformer to transform ts to js and it doesn't do anything with the way how Jest resolves a file. ts-jest can add a section to documentation regarding to this error but natively, it is not ts-jest issue so the resolver should stay on its own, not included in ts-jest

The issue is mainly caused by when using js extension, Node treats it as CommonJS, if you don't have module.exports it is not a valid js to Node to import.

It is important to distinguish between runtime error vs type checking error. Runtime errors are from Jest and type checking errors are from ts-jest.

[VitorLuizC]

TS resolves module imports when using ".js" extension, ts-jest should do the same in jest. Or at least a explanation on how to do it, since its treated by TS, but not by ts-jest when using TS and jest.

[ahnpnl]

ts-jest doesn't do anything with Jest module resolution. The job of ts-jest is transforming ts to js. Transforming means compiling. Compiling process doesn't trigger the codes itself.

The output of import { MyType } from "./types.js"; is

var globals_1 = require(\\"./types.js\\");

This is a correct js compiling. However, how that require(\\"./types.js\\") executes depending on Jest.

As I said above, ts-jest is a Jest transformer, please check https://jestjs.io/docs/next/code-transformation to understand more.

[VitorLuizC]

In README.md the description is "It supports all features of TypeScript including type-checking.", and i'm using as a preset, not a transformer. But no problem, I can make a package just to resolve module in jest same way TypeScript does.

[ahnpnl]

Actually, the preset means "A Jest configuration". This preset includes a transformer, which compiles ts into js. I know it's a bit hard to understand what's going on in internal ts-jest.

What tsc does is actually compiling ts into js, but if you need to execute js, tsc won't do it for you. This is the same like Jest + ts-jest. ts-jest takes care of compiling ts into js and gives the compiled js back to Jest. After that, Jest will execute the compiled js using V8 VM.

It supports all features of TypeScript including type-checking this means TypeScript language features, something like decorators (which is ECMA proposal stage 2), etc... This makes sure that the output js is understandable to V8 VM. See more at https://kulshekhar.github.io/ts-jest/docs/next/processing

[joeldenning]

I got things working with .js extensions in typescript imports with the following jest.config.js:

/**  @type {import('@jest/types').Config.ProjectConfig} */
const config = {
  transform: {
    "\\.[jt]sx?$": "ts-jest",
  },
  "globals": {
    "ts-jest": {
      "useESM": true
    }
  },
  moduleNameMapper: {
    "(.+)\\.js": "$1"
  },
  extensionsToTreatAsEsm: [".ts"],
};

export default config;

[fkleedorfer]

This comment started me on the right path, but for my project, the solution is simpler: make sure the moduleNameMapper only maps the '.ts' files that you refer to as .js in your imports elsewhere. In my case, those were the ./[filename].ts files, which are imported as ./[filename].js but for jest need to be imported as ./[filename].

In jest.config.json syntax:

"moduleNameMapper": {
    "^(\\.\\/.+)\\.js$": "$1"
  },

[justrhysism]

I tweaked the above version to allow ../ relative imports also:

"moduleNameMapper: {
    "^(\.\.?\/.+)\.jsx?$": "$1"
}

[maranomynet]

@justrhysism you must double the backslashes:

    "moduleNameMapper: {
        "^(\\.\\.?\\/.+)\\.jsx?$": "$1"
    }

[trusktr]

custom resolver doesn't belong to ts-jest.

@ahnpnl In my very humble opinion, if someone gives a Jest plugin for people to write .test.ts files instead of .test.js files, but it doesn't work with default functionality of TypeScript, then that's the plugin author's problem, not Jest's.

.js extensions for module specifiers are a default out-of-the-box feature of TypeScript.

[davidkhala]

I got things working with .js extensions in typescript imports with the following jest.config.js:

/**  @type {import('@jest/types').Config.ProjectConfig} */
const config = {
  transform: {
    "\\.[jt]sx?$": "ts-jest",
  },
  "globals": {
    "ts-jest": {
      "useESM": true
    }
  },
  moduleNameMapper: {
    "(.+)\\.js": "$1"
  },
  extensionsToTreatAsEsm: [".ts"],
};

export default config;

Since the global ts-jest config is considered as deprecated.

I adjust the good tips by this way

{
  "transform": {
    "\\.[jt]s?$": [
      "ts-jest",
      {
        "useESM": true
      }
    ]
  },
  "moduleNameMapper": {
    "(.+)\\.js": "$1"
  },
  "extensionsToTreatAsEsm": [
    ".ts"
  ],
  ...
}

[IdrisAkintobi]

The below works for me in my Node.js backend project. The rule applies to relative imports starting with a period (.) or double periods (..)

"moduleNameMapper": {
        "@src/(.*)": "<rootDir>/src/$1",
        "^(\\./.+|\\../.+).js$": "$1"
    }

OR

"moduleNameMapper": {
        "@src/(.*)": "<rootDir>/src/$1",
        "^(..?/.+).js?$": "$1"
    },