Add import assertions to type only imports and import types to force the resolution mode of the specifier

[weswigham]

This PR adds support for a TS-specific assertion on type-only imports and on import type nodes which forces the resolver into either require or import resolution mode, allowing access to types which the containing file's default mode would normally make difficult or impossible to access. They look like this:

import type { RequireInterface } from "pkg" assert { "resolution-mode": "require" };
import type { ImportInterface } from "pkg" assert { "resolution-mode": "import" };

export interface LocalInterface extends RequireInterface, ImportInterface {}

export type LocalType =
    & import("pkg", { assert: {"resolution-mode": "require"} }).RequireInterface
    & import("pkg", { assert: {"resolution-mode": "import"} }).ImportInterface;

This is essentially a continuation of #47732 that allows resolver configurability for more kinds of type-based imports. Since it's included in this PR, it's probably best to go and review & merge that first.

Fixes #47338 by allowing the types of an esm package to be fetched in a cjs file via these modal imports.
Fixes #47248

[TimvdLippe]

FYI the PR description claims "Fixes #47807", but this PR has number 47807

[nicolo-ribaudo]

This feels really wrong 😕

The proposal explicitly says that import assertions must not affect how a module is evaluated or resolved:

[...]
The implementation of HostResolveImportedModule must conform to the following requirements:

• [...]
• moduleRequest.[[Assertions]] must not influence the interpretation of the module or the module specifier; instead, it may be used to determine whether the algorithm completes normally or with an abrupt completion.

In other words, if both these two imports succeed they must resolve/evaluate the same file:

import { A } from "pkg" assert { "resolution-mode": "require" };
import { A } from "pkg" assert { "resolution-mode": "import" };

The imports assertions proposal even mentions a possible follow-up proposal that would allow what you need, but it would be a separate proposal (with likely different syntax).

I know that this PR is only about import type so it's technically "just TS" and not JS, but actively going against the JS semantics should be discouraged.

[nicolo-ribaudo]

https://github.com/tc39/proposal-import-reflection is probably what you need, even if it's not clear yet if it's also meant to affect resolution.

[weswigham]

These don't affect runtime and are type-only (your example above doesn't work - you have to say import type); it's fine - it's much better than introducing full on new syntax.

[nayeemrmn]

it's fine - it's much better than introducing full on new syntax.

@weswigham This is wrong, we're using the assert keyword for something that isn't an assertion. Why? You're correct that this is a type-only statement, all the more reason to do literally anything else and not misuse a JS syntax.

There are plenty of other options that make sense without completely new and ts-only syntax e.g.

// comment directive, nothing new

// @ts-resolution=require
import type { RequireInterface } from "pkg";

// https://github.com/tc39/proposal-import-reflection

import type { RequireInterface } from "pkg" as "resolution=require";

// dangles off the already ts-only part

import type(resolution=require) { RequireInterface } from "pkg";

Please consider reverting this change.

[nayeemrmn]

I've already seen a lot of people confused by import assertions and what they could be used for in runtimes, specifically conflating them with what's proposed in https://github.com/tc39/proposal-import-reflection. It would be a shame to see TS fostering that misconception, or perhaps falling victim to it.

[glen-84]

Why is it:

assert {"resolution-mode": "import"};

(requiring quotes), and not:

assert {resolutionMode: "import"};

?

[weswigham]

Consistency with the triple-slash reference form and a bit of extra syntax encumbrance to make you pause and think if you really need to use it. :)

[frehner]

Would this also hypothetically help solve the issue found at #46213 ? If so, how soon do you think this feature will graduate from nightly?