添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
相关文章推荐
忐忑的铁板烧  ·  CRS (Geotools modules ...·  4 天前    · 
腼腆的匕首  ·  js手机端日期选择插件 - ...·  18 小时前    · 
不敢表白的椰子  ·  On-the-fly machine ...·  2 月前    · 
不爱学习的风衣  ·  Introduction to ...·  3 月前    · 
一身肌肉的眼镜  ·  Central Japan ...·  5 月前    · 

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

🚀 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

    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"} ?

    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: 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)
              

    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.
              

    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.

    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.

    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?

    * refactor: yargs esm * quickfix: downgrade axios to fix type problems with axios-mock-adapter * fix import issues * jest + esm * replace global jest with import.meta.jest - https://jestjs.io/docs/ecmascript-modules#differences-between-esm-and-commonjs * install esbuild * pkg+esbuild * make it possible to run jest without npm run build * manage to get ts-node to work - when using tsx unable to get source-mapping to work * fix npm run test-except-dind * tweak tsconfig * attempt to run npm coverage without building * only way i manage to get npm run coverage to work - was getting the exact same error as per jestjs/jest#15000 * resolve esbuild warning with direct eval * fix `pkg` warnings * docs: update docs * Use @yao-pkg/pkg. Use bin/ instead of pkg/ folder * Upgrade axios * Reintroduce babel-jest * Rename github action job to smoke-test * Use node20 for pkg vm * Fix user-agent --------- Co-authored-by: Mads Jon Nielsen <[email protected]>