Skip to content
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

Design Meeting Notes, 2/24/2021 #42991

Closed
DanielRosenwasser opened this issue Feb 26, 2021 · 0 comments
Closed

Design Meeting Notes, 2/24/2021 #42991

DanielRosenwasser opened this issue Feb 26, 2021 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Removing Compatibility From Object Types to { [x: number]: any }

#41660

  • Kind of strange behavior because numeric index signatures are usually stricter.
  • This was never meant to apply to numeric index signatures. We always had string index signatures in mind.
  • Would this tightening also apply to symbol, literals, etc.?
    • Currently don't have those index signature types, but we would want the same restrictions.
  • Conclusion: seems fine.

const enums and import type

#40344 (comment)

  • In the beta period of its release, import type only allowed symbols in type positions.
  • Eventually got feedback that the point was all about emit.
  • Soon got feedback about const enums in import type because really the emit doesn't rely on it.
    • Seemed reasonable as a suggestion, said "awaiting more feedback", but got internal feedback about this.
  • Under isolatedModules, the value no longer inlines.
  • Proposal: keep error as-is if isolatedModules is on, but otherwise remove the error for using it in import type.
  • People don't always know that they're supposed to use isolatedModules.
    • But that's fundamentally the right thing to do when you use another compiler.
  • Narrative feels compelling but...
    • don't feel super strongly about this.
  • Feels strange to extend more special-cases for const enums.

Philosophy on ES Modules and the Handbook

  • Handbook talks about different module system types.
  • Maybe new handbook talks about CommonJS and ES modules.
    • Mention AMD, UMD, System exist, but want to talk about what most people will be doing in their day-to-day.
  • All of this is part of an umbrella goal for supporting ES modules in Node in general.
  • Strive for at least examples of modules in the browser, in Node.
  • Syntax, resolution, output?
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

1 participant