Skip to content

Implement Import Assertions (stage 3) #40694

Description

@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.

Activity

  1. changed the title [-]Implement Import Assertions [/-] [+]Implement Import Assertions (stage 3)[/+] on Sep 22, 2020
  2. justinfagnani commented on Sep 23, 2020

    @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.

  3. kitsonk commented on Sep 23, 2020

    @kitsonk
    Contributor

    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.

  4. justinfagnani commented on Sep 23, 2020

    @justinfagnani

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

  5. rbuckton commented on Dec 17, 2020

    @rbuckton
    Contributor

    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 Daniel Rosenwasser (@DanielRosenwasser)

  6. Kingwl commented on Jan 27, 2021

    @Kingwl
    ContributorAuthor
  7. 2 remaining items

  8. justinfagnani commented on Jun 11, 2021

    @justinfagnani

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

  9. calebdwilliams commented on Jul 4, 2021

    @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.

  10. Kingwl commented on Jul 5, 2021

    @Kingwl
    ContributorAuthor

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

  11. justinfagnani commented on Jul 30, 2021

    @justinfagnani

    Wenlu Wang (@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.

  12. Kingwl commented on Aug 16, 2021

    @Kingwl
    ContributorAuthor

    any chance for 4.5?

    As with 4.2, 4.3 and 4.4. No.

  13. IanVS commented on Sep 9, 2021

    @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?

  14. Kingwl commented on Sep 10, 2021

    @Kingwl
    ContributorAuthor

    Oh, sorry. I misread chance as change.

  15. justinfagnani commented on Sep 13, 2021

    @justinfagnani

    Wenlu Wang (@Kingwl) Ron Buckton (@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'}

  16. haoqunjiang commented on Sep 30, 2021

    @haoqunjiang

    FYI I opened a follow-up issue at #46135

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

ES NextNew featurers for ECMAScript (a.k.a. ESNext)Fix AvailableA PR has been opened for this issueNeeds InvestigationThis issue needs a team member to investigate its status.RescheduledThis issue was previously scheduled to an earlier milestoneSuggestionAn idea for TypeScript

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions