Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 3/26/2024 #57980

Open
DanielRosenwasser opened this issue Mar 28, 2024 · 0 comments
Open

Design Meeting Notes, 3/26/2024 #57980

DanielRosenwasser opened this issue Mar 28, 2024 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

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.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant