microsoft/TypeScript

Design Meeting Notes, 10/19/2022

DanielRosenwasser opened this issue ยท 2 comments

Codebase Module Migration

#49332

  • Reorganized Debug into a namespace.
    • Allows typingsInstaller to tree-shake everything else.
    • Boom, drops 5.5MB from our package size.
  • let/const - we're not going to bother downleveling that at the moment because
    1. Our exports should (often) be consts
    2. The other wins are so high that it's not an immediate priority.
      • We can revisit at a later date
  • What is our new target?
    • es2015 is safest, but is already kind of old.
    • es2016 has **, but not a huge pull
    • es2017 has async/await - we don't use it really
    • es2018 has async generators - but same as above.
    • Really, we just want to rougly guarantee that we'll continue to work in Node 10 (even though that's pretty old at this point too!)
  • Should we sort the declarations in our .d.ts?
    • No.
    • Things were intentionally colocated, we should preserve that.
  • Giant import block problem
    • Auto-imports will keep tacking imports and mess with the line length.

    • Also, most import lists are on one line...

      import { A, B, C } from "module";

      or multiple imports per line

      import {
        A,
        B,
        C,
      } from "module";

      but checker.ts has a CRAZY number of imports, and we've done a mix to avoid the worst of both (long line length vs. thousands of import lines)

      import {
        A, B, C,
        D, E, F,
        G, H, I,
      } from "module";
    • So what do we want to do?

      • Might be okay with just letting this go until we have a plan for the built-in formatter to understand line lengths.
      • Using an external formatter after-the-fact.
    • Could put them at the bottom.

      • Let's not be weird. Every language just does imports at the top. All JS devs do imports at the top.
      • [[Editor's note]]: Yes, let's not be weird in our ~50K LoC file.
    • Maybe it's time to break parts of checker.ts out.

    • Let's do nothing for now.

  • Can we drop our internal Map types?
    • We dropped our shims in a recent version, nobody has complained yet.
    • Can we just take/provide Maps and ReadonlyMap?
    • Maybe in the next version, but not necessarily in the initial PR.
    • ๐Ÿ‘

Enums Unifications and Improvements

#50528

  • Computed expressions on enum members would swap an enum over to a numeric enum, which preserves no information about the singleton types that each member represents.

    • Meant you would get no control flow analysis on bindings who are assigned these enums.
  • PR changes numeric enums to still be literal-ish.

    • When enums are computed and we cannot follow the computation, we now create an "opaque enum member".
      • These are assignable to number and and the containing enum, but nothing becomes assignable to it.
  • Enums that contain these numeric members still allow assignments from any other number to support the bitflags case.

  • PR also allows

    • concatenation from template string expressions.
    • references to literal-initialized const variables.
  • Most people are just using union enums. Not a huge performance effect. Things in our perf suite were not affected. Identified one questionable issue in VS Code. 4 new errors in our compiler. One is #9998.

  • Aside - lots of cases where people want to extend enums (#17592)

    enum E10 {
      A, B, C,
    }
    
    enum E11 {
      ...E10,
      D,
      E,
    }
    • No good way to really emulate that.
      • Almost 600 upvotes on our issue tracker
    • Doing more in the enum space feels iffy - is runtime behavior, but is runtime behavior that TypeScript already kind of has made.
    • Some things in the pipeline for ECMAScript... though that proposal would be radically different anyway.
    • Our enums have relatively little value for JS users - it's the same as an object literal for the most part.
    • ES proposal does intend to keep some of TS behavior.
      • "Scalar enums"
    • We don't feel good treading this ground even if TypeScript has set a lot of precedent - lots of occasions where the "simple obvious" language feature has issues with what actually lands in ECMAScript.

[[Editor's note]]: Yes, let's not be weird in our ~50K LoC file.

๐Ÿคฃ

Just to clarify, the ES syntax we decided on was ES2018, what Node 10 supports. That leaves our codebase without any downleveing helpers.