2

I'm switching my TypeScript project to a (pnpm) monorepo and have troubles getting tests to run properly. I have a jest.config.js that uses a custom testEnvironment that's written in TypeScript as well. However, ever since I moved the specific project into my packages directory for the monorepo restructuring, jest throws an Error and doesn't run any tests:

    TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for C:\workspaces\repos\the-monorepo\packages\testproject\source\testtools\jsdom-environment-global.spec.ts

I tried it with @swc/jest as well as with ts-jest, had a look at How to use TypeScript in a Custom Test Environment file in Jest? (which makes me think "why did this ever work?") and, for whatever reason, it worked fine yesterday. I cleaned jest cache and reinstalled all node_modules to no avail. I also found answers related to "type": "module" in package.json, but this doesn't apply to my package. It's not an ESM.

Here's how the jest.config.js looks like:

/** @type {import('@jest/types').Config.InitialOptions} */
const config = {
    silent: true,
    testEnvironment: "<rootDir>/source/testtools/jsdom-environment-global.spec.ts",
    roots: [
        "<rootDir>/source"
    ],
    maxWorkers: "50%",
    transform: {
        "^.+\\.(t|j)s$": ["@swc/jest", {
            sourceMaps: "inline",
            module: {
                strict: false,
                strictMode: false
            },

            jsc: {
                target: "es2021",
                parser: {
                    syntax: "typescript",
                    dynamicImport: true
                }
            }
        }]
    },
    transformIgnorePatterns: [
        "node_modules"
    ],
    testMatch: [
        "**/*/*.spec.ts",
        "**/*/*.test.ts",
        "!**/playwright-tests/**",
        "!**/playwright-tests-smoke/**"
    ],
    moduleFileExtensions: ["ts", "js", "node", "json"],
    reporters: [
        "default"
    ],
    globals: {
        self: {},
        navigator: {},
        jasmine: {},
        __UNIT__: true
    },
    coverageDirectory: "test-results",
    collectCoverage: false,
    collectCoverageFrom: [
        "./source/**/*.ts"
    ],
    coveragePathIgnorePatterns: [
        "/\\.spec\\.ts$/i",
        "/.*node_modules.*/",
        "/.*testtools.*/"
    ],
    coverageReporters: [
        "lcov", "cobertura"
    ],
    coverageProvider: "v8",
    resetMocks: true,
    restoreMocks: true,
    resetModules: true,
    setupFilesAfterEnv: [
        "jest-extended/all",
        "<rootDir>/source/testtools/setup.spec.ts"
    ],
    testPathIgnorePatterns: [
        "<rootDir>/source/testtools/",
        "<rootDir>/source/smoke-tests/",
        "<rootDir>/source/performance-tests/",
        "<rooDir>/source/playwright-tests/",
        "<rooDir>/source/playwright-tests-smoke/"
    ],
    moduleNameMapper: {
        "^@test-helpers": "<rootDir>/source/testtools/index.spec.ts",
        "^@test-tools/(.*)": "<rootDir>/source/testtools/$1",
        '^(\\.{1,2}/.*)\\.js$': '$1'
    }
};
module.exports = config;

Why is jest not able to parse the testEnvironment if it's a TypeScript file?

Gernot Raudner
  • 814
  • 7
  • 21

1 Answers1

0

I found the issue: there seems to be some confusion around the transformer not being applied to ESM files. In my case, the jsdom-environment-global.spec.ts imported an ESM module from a different package within my monorepo. This import triggers an exception because jest tries to import it via require(), which is caught and then again imported via dynamic imports. This dynamic import then throws the exception that ts is an unknown exception. I'm not sure why these files haven't been transformed, but as of How to use TypeScript in a Custom Test Environment file in Jest? this seems to be normal.

Bottom line: don't import from ESM files within your jest testEnvironment module.

Gernot Raudner
  • 814
  • 7
  • 21
  • how did you go about detecting which import was causing the issue? – Shalom Sam Feb 17 '23 at 20:04
  • 1
    i ran it in debug mode (that prints a stack trace), then followed the stack trace and added a breakpoint at the location of the error (unfortunately there's tons of imports so i had to use a conditional breakpoint with the import ending with .ts) – Gernot Raudner Feb 20 '23 at 09:08