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, 6/2/2023 #54502

Closed
DanielRosenwasser opened this issue Jun 2, 2023 · 2 comments
Closed

Design Meeting Notes, 6/2/2023 #54502

DanielRosenwasser opened this issue Jun 2, 2023 · 2 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Jun 2, 2023

Import Assertions / Import Attributes

#53656

#54242

import Resource from "./some-json-file.json" with { type: "json" };
import Resource from "./some-json-file.json" assert { type: "json" };
  • At last TC39, progressed conditionally - some paperwork to be done.
  • Babel and at least one other implementer has it.
  • Node merged (shipped?) this already.
  • Probably safe - but we want concrete stage 3 to make sure.
  • Feels like we need confidence for at least syntax - should be able to use the with syntax instead of assert as soon as it hits stage 3.
  • But new semantics are tougher - this is a feature that is largely implementation defined. Unless we have a strong vision or the community coalesces on semantics, it is hard for us to figure out.
  • Will wait on true stage 3.

Plugins!

#16607

  • 3 things we've been talking a lot about
    • Watch plugins
    • Module resolution
    • Transformer (emit)
  • Also, module resolution has some asymmetry with the language service - generating a .d.ts on the fly for a GraphQL schema/query would mean you have to save a file on disk.
    • The most common thing is for CSS.
    • Ties into issues around the System interface expecting strings instead of binary buffers.
      • How do you map back an error span back to a binary?
  • Why did we start exploring transformer plugins?
    • Wanted people to stop patching TypeScript.
    • Patchers said they'd keep maintaining ts-patch.
    • Arguable that transformer plugins just fragment things more. esbuild, swc, Babel, Bun, Deno - none of them could leverage these transformers.
      • Feels like one of the concerns is type-driven emit, right?
        • Maybe, but also having parity mismatch is its own issue between all of these compilers.
    • People do use our output, but the marketplace for TypeScript compilers is broad.
  • Really what you'd want to do is describe how the code will be changed before it hits the checker.
    • e.g. transforms over a tagged template string to give better types
    • Mixed feelings about supporting that.
    • Lose invariants - need to know which kinds of nodes occur in the tree.
      • Could do a walk of the tree.
      • Really prefer having a source of truth on disk if possible (i.e. a .d.ts file or something)
    • "Running" things in the type system is slow and hits recursion limiters. Eventually might need to think about a way to enable these scenarios.
  • We probably would be best-served by splitting up the umbrella "compiler plugins" issue into 6 new issues so we can discuss them with some more clarity.
    • Watch
    • Transform
    • Resolution
    • Post-Execution (e.g. linting)
    • Post-parse
    • Mid-Check (?)
    • ...?
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jun 2, 2023
@Andarist
Copy link
Contributor

Andarist commented Jun 3, 2023

"Running" things in the type system is slow and hits recursion limiters. Eventually might need to think about a way to enable these scenarios.

Could you expand on this one? I wonder about more details about what's hiding behind this point

@RyanCavanaugh
Copy link
Member

At least once a month we have this conversation:

  • Our type system is Turing-complete and people are writing bananas types to compute wild stuff, and it's very slow
  • Well we should give them a way to just "write" code in the type system
  • That's only going to make the problem worse; every optimization we put in TS moves up the complexity of things people are writing instead of moving up the overall performance
  • Sure, but now they can write more complex stuff
  • We started this conversation because we were trying to make things faster, not more complex

image

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

3 participants