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