Use extended import assertions instead of new ignored syntax

[rockerest]

Instead of modified syntax that the engine would ignore, leverage the existing Stage 3 import-assertions proposal.

As a concrete example, the Importing and exporting types section could be modified to look something like:

import { Person } from "schema" assert { "type": "type" };

This avoids the potential problems associated with a single value import assertion as suggested here (import type ...).

---

As less concrete examples, consider converting this proposal into a new type of import assertion or even the extended import assertion with evaluator attributes.

An extended evaluator attribute could be used to treat TypeScript-syntax the way this proposal outlines, without any of the downsides:

• Relying on an import evaluator attribute would be "reversible" in the sense that it doesn't fundamentally change the language
• The particular syntax ECMAScript ignores can be variable, or change over time
• It will be clear when code a developer sees with their eyes is inert to JavaScript or not

Some examples:

import { parseSourceFile } from "./parser" assert { "type": "language" } with { "language": "ms:typescript" };

Here, the assertion tells the engine to hand off parsing control to a different evaluator. In this case, it's "ms:typescript", which borrows syntax from the built-in-modules proposal, but need not depend on it.

This could be:

import { parseSourceFile } from "./parser" assert { "type": "language" } with { "language": "fb:flow" };

Or even:

import { parseSourceFile } from "./parser" assert { "type": "language" } with { "language": "./typescript-parser.js" };

Presumably, the "language" evaluator attribute would be specified to allow some kind of override of ECMAScript syntax, or even a full replacement of the parser.

---

By using and extending import assertions, developer tooling can remain dynamic and rapidly evolving without dramatic and - critically - irreversible changes to the language itself.

[ljharb]

This means the person specifying the types of a module is the importer, instead of the author - which is categorically incorrect. Only the author should be defining the types of a thing (in the common case, at least - obv the ability of consumers to override is valuable).

[giltayar]

To continue @ljharb point: would you want to need to change all import statements whenever you switch a type system? I believe not. The way I see it: the type system used by the module is the sole concern of the module, and not the importer.

[perymimon]

I think the suggestion of throwing the type assertion to a different file is interesting, what I initially thought you meant
But in the context of what you really said the writers' claims above are are right