Support import attributes

[Ayc0]

🙋 feature request

Hello dear Parcel maintainers 👋

I'm opening this to propose supporting import assertions in parcel. I looked at the issues I don't think this was proposed yet (the only issue mentioning import assertions is #3757 but it doesn't talk about this).

Import assertions (see https://github.com/tc39/proposal-import-assertions) are getting added to the standard. And some tools already support it (like Deno).

As parcel tries to follow the regular JS spec as close as possible (for instance with workers new Worker(new URL('worker.js', import.meta.url), {type: 'module'})), this could be a good addition to parcel.

So we could do import file from "./version.json" assert { type: "json" } in addition to import file from "./version.json" to import a JSON file.

This could allow us to maybe do something like import file from "./file" assert { type: "pipeline" } in addition to import file from "pipeline:./file" for named pipelines.

🤔 Expected Behavior

By default, this would only work for JSON, but we could also use it to apply the named pipeline to imports.

😯 Current Behavior

At the moment, parcel crashes on those:

💁 Possible Solution

SWC already supports it (playground) and babel too with the plugin @babel/plugin-syntax-import-assertions

SWC

Input:

require( '@swc/core-linux-x64-gnu');
const swc = require("@swc/core");

const { Visitor } = require("@swc/core/Visitor.js");

class MyVisitor extends Visitor {
  visitImportDeclaration(node) {
    console.log(JSON.stringify(node,null,2));
    return node;
  }
}

swc
  .transformSync("import a from 'b' assert {type:'json'}", {
    // Some options cannot be specified in .swcrc
    filename: "input.js",
    sourceMaps: true,
    isModule: false,
    jsc: {
      parser: {
        syntax: "ecmascript",
        "importAssertions": true
      },
    },
  plugin: (m) => new MyVisitor().visitProgram(m),
});

Output:

{
  "type": "ImportDeclaration",
  "span": {
    "start": 0,
    "end": 38,
    "ctxt": 0
  },
  "specifiers": [
    {
      "type": "ImportDefaultSpecifier",
      "span": {
        "start": 7,
        "end": 8,
        "ctxt": 0
      },
      "local": {
        "type": "Identifier",
        "span": {
          "start": 7,
          "end": 8,
          "ctxt": 0
        },
        "value": "a",
        "optional": false
      }
    }
  ],
  "source": {
    "type": "StringLiteral",
    "span": {
      "start": 14,
      "end": 17,
      "ctxt": 0
    },
    "value": "b",
    "hasEscape": false,
    "kind": {
      "type": "normal",
      "containsQuote": true
    }
  },
  "typeOnly": false,
  "asserts": {
    "type": "ObjectExpression",
    "span": {
      "start": 25,
      "end": 38,
      "ctxt": 0
    },
    "properties": [
      {
        "type": "KeyValueProperty",
        "key": {
          "type": "Identifier",
          "span": {
            "start": 26,
            "end": 30,
            "ctxt": 0
          },
          "value": "type",
          "optional": false
        },
        "value": {
          "type": "StringLiteral",
          "span": {
            "start": 31,
            "end": 37,
            "ctxt": 0
          },
          "value": "json",
          "hasEscape": false,
          "kind": {
            "type": "normal",
            "containsQuote": true
          }
        }
      }
    ]
  }
}

🔦 Context

One of the possibilities offered by this is to be able to re-use the same spec-compliant syntax across all bundlers (if others also decide to support this)

💻 Examples

[devongovett]

I don't think we can use import assertions like we do pipelines. They are only meant for actual assertions, not transformations.

Implementations are not permitted to interpret a module differently at multiple import sites if the only difference between the sites is the set of import assertions. Future follow-up proposals may relax this restriction with "evaluator attributes" that would change the contents of the module.

See https://github.com/tc39/proposal-import-assertions#follow-up-proposal-evaluator-attributes

[Ayc0]

Now that the proposal was updated to be able to indicate the module type:

import json from "./foo.json" with { type: "json" };
import("foo.json", { with: { type: "json" } });

But also to allow for any extensible object in the with clause, should this issue be re-opened?

[mischnic]

Import attribute could replace query parameters/be another source for asset.query: https://parceljs.org/plugin-system/transformer/#query-parameters