[Feature]: Support tc39 "import attributes"

[josundt]

🚀 Feature Proposal

I've seen from previous issues that Jest support for import assertions was already added when the proposal was at tc39 stage 3, but that this was reverted/removed again in Feb 2023 as the proposal had been demoted back to stage 2.

Right after this, in March 2023 (more than 1 year back); the proposal went back to stage 3 with a few design changes (keyword assert changed to with), and the of the name of the proposed feature has changed from "import assertions" to "import attributes".

Old proposal
New proposal

Import attributes are now supported in:

• TypeScript (since v5.3).
• Bundlers (Tested: WebPack - requires some configuration).
• Certain browsers (latest) natively (Tested: chromium).
• NodeJS LTS natively (experimental) (Tested 20.11.1).

Our developer team could have written future-proof ECMAScript code, utilizing this upcoming feature - we currently only need it to work with TypeScript and WebPack; but unfortunately it breaks the Jest tests.

When will you add support for import attributes?
Jest is currently our only obstacle...

Motivation

Jest should support the complete ECMAScript module import specs

Example

No response

Pitch

Jest should support the complete ECMAScript module import specs

[fregante]

How are they "not supported"? What breaks? #14345 seems to suggest that the user is already able to use them since tests go through babel.

Does this work? Are you using the native ESM support?

import './file.json' with {type: "json"}?

[josundt]

@fregante

My project is a TypeScript ESM project:

• package.json has the type property set to "module"

• all imports in the TypeScript code are using .js file extensions, also for TypeScript module imports (as recommeneded to have TypeScript compile to true ESM modules).

• the tsconfig.json file has the following effective, potentiallty relevant compiler options:

  {
    "compilerOptions": {
      // ...
      "esModuleInterop": true,
      "verbatimModuleSyntax": true,
      "target": "es2021",
      "moduleResolution": "nodenext",
      "module": "nodenext",
      "resolveJsonModule": true,
      "moduleDetection": "force",
      "isolatedModules": true,
      "allowSyntheticDefaultImports": true,
      "resolvePackageJsonExports": true,
      "resolvePackageJsonImports": true
    }
  }

• I am using the installed package ts-jest to resolve imports, with the following relavant configuration properties in jest.config.js:

  const config = {
      // ...
      moduleNameMapper: {
          "^(\\.{1,2}/.*)\\.js$": "$1"
      },
      transform: {
          "^.+\\.tsx?$": ["ts-jest", {
              tsconfig: "tsconfig.json",
              useESM: true
          }]
      },
      extensionsToTreatAsEsm: [".ts", ".tsx"],
      // ...
  };

• I am using running the tests with the following command:
  node --experimental-vm-modules --node_modules/jest/bin/jest.js --coverage

• JSON imports does not work with type attributes (or assertions):

  import "./file.json" with { type: "json" } // => fails when running the Jest tests

[fregante]

Thanks for the details. What's the exact error you're seeing? Since Jest sees transpiled code, my guess is that the transpiler is misconfigured

[josundt]

@fregante: The import with the "import attribute" is in an untested file.
The test execution currently fails when generating coverage for untested files.
This is the error message I get:

STACK: SyntaxError: /my-project/src/target.ts: Support for the experimental syntax 'importAttributes' isn't currently enabled (1:45):

> 1 | import settings from "./settings.json" with { type: "json" };

Add @babel/plugin-syntax-import-attributes (https://github.com/babel/babel/tree/main/packages/babel-plugin-syntax-import-attributes) to the 'plugins' section of your Babel config to enable parsing.

If you already added the plugin for this syntax to your config, it's possible that your config isn't being loaded.
You can re-run Babel with the BABEL_SHOW_CONFIG_FOR environment variable to show the loaded configuration:
        npx cross-env BABEL_SHOW_CONFIG_FOR=/my-project/src/target.ts <your build command>
See https://babeljs.io/docs/configuration#print-effective-configs for more info.

    at constructor (/my-project/node_modules/@babel/parser/lib/index.js:353:19)
    at Parser.raise (/my-project/node_modules/@babel/parser/lib/index.js:3277:19)
    at Parser.expectPlugin (/my-project/node_modules/@babel/parser/lib/index.js:3305:16)
    at Parser.expectImportAttributesPlugin (/my-project/node_modules/@babel/parser/lib/index.js:10729:12)
    at Parser.maybeParseImportAttributes (/my-project/node_modules/@babel/parser/lib/index.js:13792:16)
    at Parser.parseImportSourceAndAttributes (/my-project/node_modules/@babel/parser/lib/index.js:13702:10)
    at Parser.parseImportSpecifiersAndAfter (/my-project/node_modules/@babel/parser/lib/index.js:13696:17)
    at Parser.parseImport (/my-project/node_modules/@babel/parser/lib/index.js:13687:17)
    at Parser.parseStatementContent (/my-project/node_modules/@babel/parser/lib/index.js:12347:27)
    at Parser.parseStatementLike (/my-project/node_modules/@babel/parser/lib/index.js:12239:17)
    at Parser.parseModuleItem (/my-project/node_modules/@babel/parser/lib/index.js:12216:17)
    at Parser.parseBlockOrModuleBlockBody (/my-project/node_modules/@babel/parser/lib/index.js:12796:36)
    at Parser.parseBlockBody (/my-project/node_modules/@babel/parser/lib/index.js:12789:10)
    at Parser.parseProgram (/my-project/node_modules/@babel/parser/lib/index.js:12116:10)
    at Parser.parseTopLevel (/my-project/node_modules/@babel/parser/lib/index.js:12106:25)
    at Parser.parse (/my-project/node_modules/@babel/parser/lib/index.js:13905:10)
    at parse (/my-project/node_modules/@babel/parser/lib/index.js:13947:38)
    at parser (/my-project/node_modules/@babel/core/lib/parser/index.js:41:34)
    at parser.next (<anonymous>)
    at normalizeFile (/my-project/node_modules/@babel/core/lib/transformation/normalize-file.js:64:37)
    at normalizeFile.next (<anonymous>)
    at run (/my-project/node_modules/@babel/core/lib/transformation/index.js:21:50)
    at run.next (<anonymous>)
    at transform (/my-project/node_modules/@babel/core/lib/transform.js:22:33)
    at transform.next (<anonymous>)
    at evaluateSync (/my-project/node_modules/gensync/index.js:251:28)
    at sync (/my-project/node_modules/gensync/index.js:89:14)
    at stopHiding - secret - don't use this - v1 (/my-project/node_modules/@babel/core/lib/errors/rewrite-stack-trace.js:47:12)
    at transformSync (/my-project/node_modules/@babel/core/lib/transform.js:42:76)
    at ScriptTransformer._instrumentFile (/my-project/node_modules/@jest/transform/build/ScriptTransformer.js:389:46)
    at ScriptTransformer._buildTransformResult (/my-project/node_modules/@jest/transform/build/ScriptTransformer.js:491:33)
    at ScriptTransformer.transformSourceAsync (/my-project/node_modules/@jest/transform/build/ScriptTransformer.js:608:17)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async generateEmptyCoverage (/my-project/node_modules/@jest/reporters/build/generateEmptyCoverage.js:127:20)

[fregante]

Yep, that's a babel error, not a Jest/Node one. Just follow the instructions it provides.

[josundt]

I'm not using babel, and my project has no (direct) dependencies to any babel packages.
I relate only to the jest packages; -the babel packages are dependencies of jest packages.

As stated by jest in the information written to the terminal along with the error message (see complete content below):

"Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration."

I don't use babel, and don't have any babel configuration file; and I think I should not have to add one just to make jest work with import attributes. It looks like things would have worked if the @babel/plugin-syntax-import-attributes was added to the babel configuration (see info below).

Proposal: The @babel/plugin-syntax-import-attributes plugin should be included in Jests babel configuration by default to ensure coverage reporting works even for code using "import attributes".

Additional info: I have now written a test for a module that uses "import attributes".
The test execution actually works without no error; but when adding the --coverage parameter the error is thrown.

This is the complete informational content written to the terminal when the test fails (I did not include everything in my previous post).

Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when 
Jest is not configured to support such syntax.

Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.

By default "node_modules" folder is ignored by transformers.

Here's what you can do:
• If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.
• If you are trying to use TypeScript, see https://jestjs.io/docs/getting-started#using-typescript
• To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.
• If you need a custom transformation specify a "transform" option in your config.
• If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.

You'll find more details and examples of these config options in the docs:
    https://jestjs.io/docs/configuration
For information about custom transformations, see:
    https://jestjs.io/docs/code-transformation

Add @babel/plugin-syntax-import-attributes (https://github.com/babel/babel/tree/main/packages/babel-plugin-syntax-import-attributes) to the 'plugins' section of your Babel config to enable parsing.

If you already added the plugin for this syntax to your config, it's possible that your config isn't being loaded.
You can re-run Babel with the BABEL_SHOW_CONFIG_FOR environment variable to show the loaded configuration:
  npx cross-env BABEL_SHOW_CONFIG_FOR=D:\_Git\Adra.Reference.App\src\Adra.Reference.App\src\climate\climate-environment-loader.ts <your build command>
See https://babeljs.io/docs/configuration#print-effective-configs for more info.

[AntonioFavero]

I have the same problem. Jest works perfectly with import assert. However, with coverage, the error occurs. I'm using ts-jest.

NODE_OPTIONS=--experimental-vm-modules jest --coverage

SyntaxError: /swagger.ts: Support for the experimental syntax 'importAttributes' isn't currently enabled (1:47):

> 1 | import packageJson from './package.json' with { type: 'json' };

@josundt;

Even using ts-jest, I see that the use of babel is fixed in the source.

[github-actions]

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

[josundt]

@fregante What's happening here?

[nicolo-ribaudo]

Jest uses https://github.com/nicolo-ribaudo/babel-preset-current-node-syntax to know which Babel plugins to enable. If somebody can submit a PR to that repo for import attributes, I can release a new version.

[SimenB]

I just filed nicolo-ribaudo/babel-preset-current-node-syntax#9 which I guess is pretty much the issue equivalent of what @nicolo-ribaudo requested above 😀

[nicolo-ribaudo]

I published a new minor version of the Babel plugin, this should work now.

[bobmorley]

Running into a similar problem, but we use the @babel/plugin-syntax-import-assertions plugin.

What is interesting to me, is that if I configure the coverage to not target where to collect (removing collectCoverageFrom) it seems to collect on only the files jest touched when it executed. Since the jest runner tranformed them, it collects properly. It is only the files that jest didn't touch that cause that cause the failure.

So my hack workaround is to not specify collectCoverageFrom (resulting in artificially high metrics)

@nicolo-ribaudo does your version to the attributes plugin have to be applied to assertions? How do you get babel to use your version as part of the coverage transform? Just yarn adding and getting your new minor version didn't seem to work.

[SimenB]

Make sure to dedupe afterwards so Jest picks up the correct version of the preset

[bobmorley]

Make sure to dedupe afterwards so Jest picks up the correct version of the preset

This is cool to know, and it did indicate it did it -- but it still fails after jest has executed when attempting to collect coverage on files that jest didn't specifically transform. My current understanding is that when jest runs it will use my transform to apply the .babelrc that I have defined, and everything works. But when code coverage has to run and it hits files that babel didn't transform, it attempts to transform on its own using these presets which then fail? idk ...

Right now my devDependencies look like this:

    "devDependencies": {
        "@babel/core": "^7.22.5",
        "@babel/eslint-parser": "^7.22.5",
        "@babel/plugin-syntax-import-assertions": "^7.24.7",
        "@babel/plugin-syntax-import-attributes": "^7.24.7",
        "@babel/plugin-transform-runtime": "^7.24.7",
        "@babel/preset-env": "^7.25.3",
        "@babel/runtime": "^7.25.0",
        "babel-jest": "^29.6.1",
        "babel-plugin-transform-amd-to-commonjs": "^1.6.0",
        "babel-plugin-transform-import-meta": "^2.2.1",
        "babel-preset-current-node-syntax": "^1.1.0",
        "cross-env": "^7.0.3",
        "eslint": "^8.42.0",
        "eslint-config-airbnb-base": "^15.0.0",
        "eslint-config-prettier": "^8.8.0",
        "eslint-plugin-import": "^2.27.5",
        "eslint-plugin-jest": "^27.2.3",
        "eslint-plugin-n": "^16.3.1",
        "eslint-plugin-only-warn": "^1.1.0",
        "eslint-plugin-prettier": "^4.2.1",
        "jest": "^29.7.0",
        "jest-junit": "^16.0.0",
        "prettier": "^2.8.8"
    },

And I have run dedupe which did indicate it replaced the old babel-preset-current-node-syntax with this new one that should include the fix. Perhaps I am missing obvious?