GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Add import assertions to type only imports and import types to force the resolution mode of the specifier by weswigham · Pull Request #47807 · microsoft/TypeScript

Conversation

@weswigham

@weswigham Wesley Wigham (weswigham) commented Feb 8, 2022 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Member

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

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

motss, worstpractice, and alexeden reacted with hooray emoji happycollision, OctoD, and worstpractice reacted with heart emoji jaydenseric, ExE-Boss, robpalme, worstpractice, and nokazn reacted with eyes emoji
All reactions
  • 🎉 3 reactions
  • ❤️ 3 reactions
  • 👀 5 reactions
@weswigham
Wesley Wigham (weswigham) requested review from Andrew Branch (andrewbranch) and Ron Buckton (rbuckton) February 8, 2022 23:26
@typescript-bot TypeScript Bot (typescript-bot) assigned Wesley Wigham (weswigham) and unassigned Wesley Wigham (weswigham) Feb 8, 2022
@typescript-bot TypeScript Bot (typescript-bot) added Author: Team For Milestone Bug PRs that fix a bug with a specific milestone labels Feb 8, 2022
RyanCavanaugh
Ryan Cavanaugh (RyanCavanaugh) reviewed Feb 9, 2022
View reviewed changes
Comment thread tests/baselines/reference/nodeModulesImportTypeModeDeclarationEmitErrors1(module=node12).js Resolved

Uh oh!

There was an error while loading. Please reload this page.

@typescript-bot TypeScript Bot (typescript-bot) added the Fix Available A PR has been opened for this issue label Feb 10, 2022
@weswigham Wesley Wigham (weswigham) mentioned this pull request Feb 10, 2022
Allow synchronous type-only import of ESM package from CJS #47248
Closed
5 tasks done
@TimvdLippe

Tim van der Lippe (TimvdLippe) commented Feb 12, 2022

Copy link
Copy Markdown
Contributor

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

weswigham and kaznovac reacted with laugh emoji
All reactions
  • 😄 2 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@weswigham
Wesley Wigham (weswigham) force-pushed the import-modal-assertions branch from 45e3c3d to 355ae11 Compare February 15, 2022 21:55
@weswigham
Add import assertions for type-only imports and import types to chang…
476dc6d
…e resolver modes
@weswigham
Wesley Wigham (weswigham) force-pushed the import-modal-assertions branch from 355ae11 to 476dc6d Compare February 15, 2022 22:03
@weswigham Wesley Wigham (weswigham) removed the Fix Available A PR has been opened for this issue label Feb 15, 2022
andrewbranch
Andrew Branch (andrewbranch) requested changes Feb 16, 2022
View reviewed changes
Comment thread src/compiler/program.ts Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread src/compiler/types.ts Resolved

Uh oh!

There was an error while loading. Please reload this page.

This was referenced Feb 23, 2022
Design Meeting Notes, 2/9/2022 #48016
Closed
TypeScript 4.7 Iteration Plan #48027
Closed
Wesley Wigham (weswigham) added 3 commits February 28, 2022 13:34
@weswigham
Merge branch 'main' into import-modal-assertions
8b2eb94
@weswigham
By popular request, only allow mode assertions on top-level type only…
dcc7329
… imports
@weswigham
Add specifier options parameter to specifier generation
2f20f61
andrewbranch
Andrew Branch (andrewbranch) approved these changes Mar 1, 2022
View reviewed changes
@weswigham
Wesley Wigham (weswigham) merged commit ea0db9e into microsoft:main Mar 2, 2022
@nicolo-ribaudo

Nicolò Ribaudo (nicolo-ribaudo) commented Mar 30, 2022 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

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.

nayeemrmn, MierenManz, DjDeveloperr, KyleJune, and dsherret reacted with thumbs up emoji
All reactions
  • 👍 5 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@nicolo-ribaudo

Nicolò Ribaudo (nicolo-ribaudo) commented Mar 30, 2022 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

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.

KyleJune reacted with thumbs up emoji
All reactions
  • 👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@weswigham

Wesley Wigham (weswigham) commented Mar 30, 2022 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Member Author

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.

KyleJune reacted with thumbs down emoji
All reactions
  • 👎 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@nayeemrmn

Nayeem Rahman (nayeemrmn) commented Apr 9, 2022

Copy link
Copy Markdown

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

Wesley Wigham (@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.

KyleJune and dsherret reacted with thumbs up emoji
All reactions
  • 👍 2 reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@nayeemrmn

Nayeem Rahman (nayeemrmn) commented Apr 9, 2022

Copy link
Copy Markdown

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.

KyleJune reacted with thumbs up emoji
All reactions
  • 👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@glen-84

Glen (glen-84) commented Apr 9, 2022

Copy link
Copy Markdown

Why is it:

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

(requiring quotes), and not:

assert {resolutionMode: "import"};

?

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@weswigham

Wesley Wigham (weswigham) commented Apr 9, 2022

Copy link
Copy Markdown
Member Author

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

glen-84 reacted with confused emoji
All reactions
  • 😕 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@dsherret David Sherret (dsherret) mentioned this pull request Apr 11, 2022
Consider redesigning "resolution-mode" to not be an assertion since it's not an assertion #48644
Closed
@RebeccaStevens Rebecca Stevens (RebeccaStevens) mentioned this pull request May 30, 2022
Cannot import a package with "type": "module" from cjs even if the package has an exports map #49299
Closed
@frehner

Anthony Frehner (frehner) commented Oct 8, 2022 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown

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

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

@frehner Anthony Frehner (frehner) mentioned this pull request Oct 8, 2022
Add scripts that modify the package.json before publishing tajo/ladle#275
Merged
@kf6kjg Ricky Curtice (kf6kjg) mentioned this pull request Mar 14, 2023
Time to upgrade again - semantic-release is now ESM :/ semantic-release-plus/semantic-release#292
Open
@microsoft Microsoft (microsoft) locked as resolved and limited conversation to collaborators Oct 22, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@RyanCavanaugh Ryan Cavanaugh (RyanCavanaugh) RyanCavanaugh left review comments
@andrewbranch Andrew Branch (andrewbranch) andrewbranch approved these changes
@rbuckton Ron Buckton (rbuckton) Awaiting requested review from rbuckton

Uh oh!

There was an error while loading. Please reload this page.

Assignees

@weswigham Wesley Wigham (weswigham)

Labels

Author: Team For Milestone Bug PRs that fix a bug with a specific milestone

Projects

PR Backlog
Archived in project

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

error importing type from esm in commonjs Allow synchronous type-only import of ESM package from CJS

Uh oh!

There was an error while loading. Please reload this page.

9 participants

@weswigham @TimvdLippe @nicolo-ribaudo @nayeemrmn @glen-84 @frehner @andrewbranch @RyanCavanaugh @typescript-bot
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.