Design Meeting Notes, 10/19/2022

[DanielRosenwasser]

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 Trade-offs in Control Flow Analysis #9998.

• Aside - lots of cases where people want to extend enums (Extending string-based 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.

[treybrisbane]

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

🤣

[jakebailey]

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