Design Meeting Notes, 5/17/2023

[DanielRosenwasser]

Order Change Between init and set in Decorators

#54267

• Pretty major behavioral change.
• Want to align with the spec, but would be an emit change.
• Do we want to bring this post-RC?
• Major bump for tslib?
• Well it is a bug fix, don't want to drag in vestigial behavior into tslib.
• Let's bring this in pre-RC, release RC a little later instead.

Divergence Among Bundlers and Our Module Settings

#54102

• When bundlers see an __esModule property on a CJS module that gets imported with an import statement, they pretend the consumed module is ESM.
  • However, Node doesn't, and some bundlers disable this behavior in .mjs files (and maybe in .js files when they see "type": "module" in a package.json) so they can bundle code written for Node
• --moduleResolution bundler doesn't handle this
  • Not really a moduleResolution thing, it's more of a check-and-emit thing.
• Aside-ish, do these respect package.json "type"? Webpack does, need to check for others.
• Webpack doesn't understand .mts files should be treated the same the same as .mjs files.
• Are these behaviors intentional? Should we check with esbuild?
  • Pretty sure yes, to improve compatibility with Node. Adopting Node-like behavior in .mjs files is probably a good idea, and treating .mts like .mjs is definitely good.
• We're pretty sure that Webpack doesn't try to specially recognize TypeScript. If they don't want to hard-code special behavior for TS file extensions, maybe this can be added to the loader API (if it's not already there).
• We'll reach out to the Webpack people to see if we can make these play better.
  • Need to check the behavior of other bundlers and follow up with them too.

Indicator to Compiler Options for Generated Declaration Files

#54212

• This code isn't supposed to work because anything brought in as an import * cannot be callable.

  import * as hello from "hello";
  const greeting = hello("world");

• esModuleInterop does the thing Node and some bundlers do, allows CJS to be brought in as a default import:

  import hello from "hello";
  const greeting = hello("world");

• Can't always tell everyone to use esModuleInterop.

• Library authors using esModuleInterop end up requiring downstream consumers to use esModuleInterop.

  • So we try to tell library authors not to use esModuleInterop and use import hello = require("hello").

• It would be good if we could signal something about how the declaration files were generated so that they can accurately be consumed.

• Could have comments like

  // @esModuleInterop: true

• Don't like these because they imply the could affect emit in a non-declaration file.

  • But they won't. Don't have to be valid in implementation files, we can give an error.

• Should this be syntax or comments? It's like metadata.

  • It tells us all about how to resolve the shape of the module.
  • Feels strange and feels like there's an asymmetry between declaration and implementation files.

• But there is this ambiguity for the format of declaration files - maybe not for all files?

  • mts? No ambiguity.
  • cts? Possibly actually!

• If everyone just enabled verbatimModuleSyntax would it all "just work"?

  • Yes?

• Do we need to instead make it easier to adopt verbatimModuleSyntax?

• Also, should we find a path to turn esModuleInterop to true by default?

  • Is it on by default with node16 and nodenext?
    • Yes.
  • bundler?
    • Actually allowSyntheticDefaultImports.

• This is not the first time we've heard this request - first time we heard it was to signal that a file was built with strictNullChecks. Problem solved itself over time.

• Feels like this isn't metadata for a comment, this is important data that should get its own syntax.

• Not sure how to proceed.