Skip to content

Design Meeting Notes, 3/26/2024 #57980

Open
@DanielRosenwasser

Description

@DanielRosenwasser

Format Types Consistently in Baselines and Underlining Type Node Generation

  • Apply same single-line style to copied nodes as manufactured ones #57890

  • Underline type nodes without position mappings in .types baselines weswigham/TypeScript#69

  • As we try to maximize node reuse, we realized we have no indication as to whether that is taking place apart from whitespace as a heuristic.

  • Even then, preserving whitespace isn't always desirable.

  • This PR adjusts type baselines to always apply the same formatting consistently.

  • A separate PR adds an underline to indicate when a node was synthesized.

  • What are we trying to catch here?

    • Lack of node reuse.
    • Could exhaustively check things, but better off using our current infrastructure.
  • Kind of a pain to read these.

  • Is it arguable that the underlines actually indicate that you should pay attention even if you only care about the types?

    • Maybe.
  • Aside: do we need symbol baselines?

tsc --noCheck

#57934

  • For TypeScript? Isn't that weird??
  • Idea: allows people to perform a check and a build separately.
  • Declaration emit actually surprisingly works here. Most of the information can be calculated lazily, and so it avoids a full check.
  • Unfortunately, JavaScript emit actually calculates some information in the checker.
  • This is very surprisingly fast.
  • The only downside of using --noCheck for declaration emit is that it may differ in output from stuff like union ordering (which depends on types being assigned IDs, which is sensitive to check order).
  • Our main goal is to be a type-checker.
  • How does this work with syntax errors?
    • You won't get them.
  • Unclear if it's a good idea to bring this in without making this possible for the JS side. We need to try decoupling JS emit to see what if anything regresses.
  • Mixture of support for the concept of --noCheck, but if we can unlock this for transpileModule that would be a big win.
  • Don't want to add a command line flag just yet.
  • Bike-shed a name.
    • skipCheck?
    • noCheck to parallel noEmit?

Respect type in package.json in more module modes

#57896

  • Some notable changes:
    • A .cjs module under --module esnext got emitted with ES syntax; no longer does.
    • People using .cts files under --moduleResolution bundler --module esnext (aside: nowadays --module preserve is what most of these people want), we would resolve with the import condition, now resolves with the require condition.
      • Kind of weird under --preserve, but 🤷‍♂️.
    • Under --module preserve, we issue something like verbatimModuleSyntax errors because it won't be interpreted the same way from a declaration file.
  • Did not add logic to disallow CommonJS input files. Presumably a program-level error if we wanted to add it.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Design NotesNotes from our design meetings

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions