Skip to content

Design Meeting Notes, 3/8/2023 #57755

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
DanielRosenwasser opened this issue Mar 12, 2024 · 0 comments
Closed

Design Meeting Notes, 3/8/2023 #57755

DanielRosenwasser opened this issue Mar 12, 2024 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Reusing Type Nodes from Assertion Expressions

#57587

Set impliedNodeFormat in Every Module Mode

#57570

  • Expanded traversal with
  • mdast-util-to-string exports a named toString binding.
    • However in moduleResolution: esnext and others, we permit a default import of the module.

      import mdast from "mdast-util-to-string";
      mdast.toString; // TypeScript INCORRECTLY allows this.
  • We don't under nodenext etc.
    • Because we actually track this information.
  • Idea is to consider this information in all module modes.
  • Under an older mode like commonjs/node10, we look for high-confidence indicators (e.g. mts files, package.json information).
  • Avoids issues where people have an unchecked .cjs file with module.exports incorrectly transformed to include an export {} at the end of the file.
  • We can't do perfectly, but we can catch a certain class of errors!
  • Doing package.json resolution in all modes slows things down slightly, but we might be able to optimize more.

Proactively Ship esXXXX Emit Targets

#57683

  • Some editions of the language will have no changes, or people want to just speculate and say "whatever is stable for this upcoming year.
  • Expectation among users
  • But there's a royalty-free opt-out period where features can be removed from an edition.
    • Well...this has never happened.
    • How is this possibly not at odds with the stage 3 "start implementing and possibly ship" indicator?
  • Seems reasonable to place a schedule for the target versions and libs
  • Regardless of whether there are any actual changes, it feels like adding a new "no-op" year isn't a problem.
  • Creating a version specifically seems like it's not a problem?
    • What is the strategy? Saying es2024 is an alias for es2023 means that when es2024 gets solidified, syntax stops getting transformed. That's a break.
    • Saying it's an alias for esnext is less breaky - but a feature can be stalled in stage 3 for a long time.
      • But there is a break! If TS is not able to downlevel a feature and then says "oops, we can't downlevel this for es2024".
  • Conclusion: start establishing new esXXXX targets following ratification in the standards body. Typically the 2nd plenary meeting of the year.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants