Design Meeting Notes, 10/12/2022

[DanielRosenwasser]

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 (string enum member used as "computed enum member" types as number. #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 Enable constants as computed values for string enums #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 Enable constants as computed values for string enums #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.

[Jack-Works]

but nobody on the team was building with watch mode.

do you mean gulp watch-min? I use it a lot, plz don't remove it!

[jakebailey]

In the new build, it takes quite literally 2 seconds to run "min"; are you looking for watch mode for speed, or to not have to run the build task before running the outputs?

[Jack-Works]

I use watch-min mainly for continuous type checking and the output is always fresh. The latter is important when developing with tsserver. If the tsserver is always fresh, I can run Restart TS server in my debugging VSCode session and reload the language server. If there is no watch mode, I'll need to do two things to reload it.

[jakebailey]

Most build tasks will no longer be type checking (now only needed for d.ts emit, which is only done for local, lkg, and runtests); but I am adding a watch task in VS Code which will do that if needed for the whole workspace. But, that won't get you the outputs anymore.

I'll see how bad it is to reimplement a watch mode in the new build. I avoided it since it was already half broken in the old build and nobody I talked to actually used it.

[jakebailey]

Seems like I can add something similar back, though it won't be 100% (no watch mode for the d.ts files, libs, typesmap, etc), but that's fixable in time. I'll add the tasks back to the branch.

[DanielRosenwasser]

With the ability to specify/override --noEmit on --build, it sounds like you can always just run tsc -b tsconfig.json --watch, right?

[DanielRosenwasser]

Though I guess that eats up a terminal.

[DanielRosenwasser]

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.

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

[Jack-Works]

just curious, what bundler are you using? rollup? esbuild (but it does not support es5 emit)?

[jakebailey]

esbuild, see #49332, or my stack on jakebailey#1. Or, see the PR next week, probably!