Design Meeting Notes, 10/12/2022

ESM Migration

• Transition is mostly done - running, tested, working.
• Currently awaiting some dependencies.
• Wanted to use API Extractor here.
  • Can’t shadow top-level globals (e.g. Node, Symbol)
  • Doesn’t support module augmentations.
  • We made an ad-hoc .d.ts bundler - works for us because of the nature of our API.
    • New APILibCheck test that validates that the bundler is doing its job.
      • Similar to the API sample tests.
    • Single entry-point, easy enough to support.
    • A few things to fix there.
    • --stripInternal?
      • We are more aggressive about preserving JSDoc comments than others - so we switched all the /* @internal */ comments to /** @internal */.
• What’s checker.ts look like?
  • Top of the file is awful.
  • Auto-import works, doesn’t insert in the right place.
    • Probably a case-sensitivity bug.
• What are the _namespace/ts.ts files?
  • They are “barrel” files that ensure correct initialization.
• How should new code be authored?
  • New code should reference the _namespace/ts.ts file.
  • Auto-imports just do the right thing anyhow.
• Have avoided many tooling issues around git blame thanks to a new file called .git-blame-ignore-revs.
• “Scary” that we’re not using our own emit.
  • CI will always verify that the compiler runs properly with bundling enabled.
  • Can enable that locally with hereby --bundle false
• hereby?
  • hereby!
  • The module migration will break lots of our bisect tooling anyway. Good opportunity to change stuff.
  • gulp has audit problems, 20% of our install time, not really leveraging all of the features.
  • @jakebailey made a small tool called hereby which is a quick and fast for our purposes.
  • Trade-offs?
    • No watch mode, but nobody on the team was building with watch mode.
      • Not off the table long-term.
  • Why is it called hereby?
    • It was just a funny thing to call it. Can come up with another name.
• So…when do we want to type-check?
  • Need to figure out the core team’s inner dev loop.

Enum Fixes and Improvements

#50528

• First, we consider some mixed enums to be possibly numeric enums (#40862)

  enum Stringy {
      hello = "hi"
  }
  
  enum OhNo {
      zero = 0,
      str = Stringy.hello,
  }
  
  // Today, no error.
  const x: number = OhNo.str;
  

• Another issue: when referencing a property off of a value whose symbol appears declared by an enum, then within some enum declaration, we will inline its initializer.

• In #40793, someone asked to concatenate enums to create new enums.

• The idea to fix is to more cleanly split the world between numeric and literal enums.

  • literal enum initializers are
    • string literals (no placeholders)
    • concatenation of string literals with +
    • numeric literals (possibly prefixed by + or -)
    • an identifier naming a member of the (current?) enum
  • enums are literal enums if
    • all their members have literal enum initializers
  • it is an error for any initializer to be a string literal or a string literal concatenation, outside of literal enums.

• Need to make sure bundlers/compilers work well here (e.g. esbuild, babel).

• What about the proposal for template strings in #40793?

  • Would be odd if we allowed string literal types.
    • Doesn’t feel like this is a deal-breaker.
  • What about the breaks to fix the problems with the motivating code?
    • We feel like they’re not widespread, easy to get around.

• Feel like we should separate out the fixes from the new features.

[jakebailey]

it sounds like you can always just run tsc -b tsconfig.json --watch, right?

Yes, that gets you compiler errors for the workspace, but not the outputs as those aren’t produced by tsc. I have explicitly supported this on the new branch:

Where it’ll run tsc over the whole project and you’ll get compiler errors. (it’s not very fast, though; some 8 seconds to type check)

I know it’s editor-specific, but when building VS Code, they have a build task that shows two concurrent watch steps side-by-side. We could do the same with type-checking and building.

Now that I’ve restored watch mode for the actual output files (besides non-bundler/tsc files), we can add another for the actual outputs if wanted.

[jakebailey]

esbuild, see #49332, or my stack on https://github.com/jakebailey/TypeScript/pull/1. Or, see the PR next week, probably!