`assertions` property is always array when `importAssertions` parser plugin is enabled

Bug Report

• I would like to work on a fix!

If this behaviour is intentional, I want to know the reason.

Current behavior

• REPL

assertions property of ImportDeclaration (and other nodes for import/export) is empty array when assert does not exist if importAssertions parser plugin is enabled.

AST

<div>

{
  "type": "ImportDeclaration",
  "start": 0,
  "end": 28,
  "loc": {
    "start": {
      "line": 1,
      "column": 0
    },
    "end": {
      "line": 1,
      "column": 28
    }
  },
  "specifiers": [
    {
      "type": "ImportDefaultSpecifier",
      "start": 7,
      "end": 10,
      "loc": {
        "start": {
          "line": 1,
          "column": 7
        },
        "end": {
          "line": 1,
          "column": 10
        }
      },
      "local": {
        "type": "Identifier",
        "start": 7,
        "end": 10,
        "loc": {
          "start": {
            "line": 1,
            "column": 7
          },
          "end": {
            "line": 1,
            "column": 10
          },
          "identifierName": "foo"
        },
        "name": "foo"
      }
    }
  ],
  "source": {
    "type": "StringLiteral",
    "start": 16,
    "end": 28,
    "loc": {
      "start": {
        "line": 1,
        "column": 16
      },
      "end": {
        "line": 1,
        "column": 28
      }
    },
    "extra": {
      "rawValue": "./foo.json",
      "raw": "\"./foo.json\""
    },
    "value": "./foo.json"
  },
  "assertions": []
}

</div>

Input Code

import foo from "./foo.json";

Expected behavior

The assertions property should be undefined if the assert does not exist, even if the importAssertions plugin is enabled.

We want to distinguish between import foo from ". /foo.json" and import foo from "foo.json" assert {}.

AST

<div>

{
  "type": "ImportDeclaration",
  "start": 0,
  "end": 28,
  "loc": {
    "start": {
      "line": 1,
      "column": 0
    },
    "end": {
      "line": 1,
      "column": 28
    }
  },
  "specifiers": [
    {
      "type": "ImportDefaultSpecifier",
      "start": 7,
      "end": 10,
      "loc": {
        "start": {
          "line": 1,
          "column": 7
        },
        "end": {
          "line": 1,
          "column": 10
        }
      },
      "local": {
        "type": "Identifier",
        "start": 7,
        "end": 10,
        "loc": {
          "start": {
            "line": 1,
            "column": 7
          },
          "end": {
            "line": 1,
            "column": 10
          },
          "identifierName": "foo"
        },
        "name": "foo"
      }
    }
  ],
  "source": {
    "type": "StringLiteral",
    "start": 16,
    "end": 28,
    "loc": {
      "start": {
        "line": 1,
        "column": 16
      },
      "end": {
        "line": 1,
        "column": 28
      }
    },
    "extra": {
      "rawValue": "./foo.json",
      "raw": "\"./foo.json\""
    },
    "value": "./foo.json"
  },
-  "assertions": []
}

</div>

Babel Configuration (babel.config.js, .babelrc, package.json#babel, cli command, .eslintrc)

• Filename: babel.config.js

const { parse } = require("@babel/parser");

parse(`import foo from "./foo.json"`, {
  sourceType: "module",
  plugins: ["importAssertions"],
});

Environment

Possible Solution

Additional context

[sosukesuzuki]

It’s a bit off topic, I found a bug like this because the regex can’t detect comments😄 https://github.com/prettier/prettier/issues/9645

[JLHwung]

@sosukesuzuki We could develop a prettier parser plugin that tries to differentiate these cases but eventually prettier should work on a CST to preserve/format styles.