Implement Import Assertions (stage 3)

[Kingwl]

Search Terms

esnext, import-assertions

Suggestion

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

Use Cases

Examples

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[justinfagnani]

One thing that would be great to include in the design here is a way for assertions to inform the module interface, similar to wildcard module declarations.

For instance, with CSS modules, you might match on the .css file extension right now:

declare module '*.css' {
  const stylesheet: CSSStyleSheet;
  export default stylesheet;
}

but with CSS modules and import assertions, we'd want to match on the type: 'css' assertion. Some completely made up syntax:

declare module '*' assert {type: 'css'} {
  const stylesheet: CSSStyleSheet;
  export default stylesheet;
}

And then include this declaration with the DOM typings when CSS modules are standardized.

[kitsonk]

If you have comments about the design, much better to bring them up with TC39 in the proposal: https://github.com/tc39/proposal-import-assertions. This really isn't the forum to debate ECMAScript syntax semantics.

[justinfagnani]

@kitsonk Please note I'm only talking about TypeScript syntax here. I'm well aware of the proposal and TC39's process.

[rbuckton]

For the short term, we will likely parse (but not enforce) import assertions. As far as whether/how that syntax should be applied to ambient module declarations, that's something the team will need to discuss in a future design meeting.

/cc @DanielRosenwasser

[Kingwl]

https://github.com/tc39/proposal-json-modules is stage 3 too.

[Kingwl]

Nope.

[justinfagnani]

An update here: import assertions and JSON modules have shipped in Chrome and Edge 91. CSS Modules are up next.

[calebdwilliams]

I’m working on a Rollup plugin for this feature (afterwards will move in to Webpack), but each file that uses the assert syntax is now throwing despite the fact that the functionality is working. Would love to see this prioritized so developers can feel confident using import assertions.

[Kingwl]

Sadly 4.4 has already released. We cannot add new syntax features after beta.

[justinfagnani]

@Kingwl any chance for 4.5?

Another update: Chrome and Edge are shipping CSS module scripts in 93. You can try it in beta now.

[Kingwl]

any chance for 4.5?

As with 4.2, 4.3 and 4.4. No.

[IanVS]

As with 4.2, 4.3 and 4.4. No.

It's in the 4.5 iteration plan, though. 😕

I'm just curious, what is the reason it won't be considered for 4.5?

[Kingwl]

Oh, sorry. I misread chance as change.

[justinfagnani]

@Kingwl @rbuckton since #40698 is closing this issue, should we open another for ambient module definitions?

It think adding asserts to declare module is a pretty logical way to define how import assertions work.

Ideally this would be in the DOM lib:

declare module '*' assert {type: 'css'} {
  const stylesheet: CSSStyleSheet;
  export default stylesheet;
}

With something similar in the built-in lib for assert {type: 'json'}

[haoqunjiang]

FYI I opened a follow-up issue at #46135