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, 5/19/2021 #44256

Closed
DanielRosenwasser opened this issue May 25, 2021 · 2 comments
Closed

Design Meeting Notes, 5/19/2021 #44256

DanielRosenwasser opened this issue May 25, 2021 · 2 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

ES Modules in Node

https://gist.github.com/weswigham/22a064ffa961d5921077132ae2f8da78

Resolution Settings

  • Last meeting: exports, types, typesVersions
    • types@VERSION_SPECIFIER
  • moduleResolution flag
    • node12
  • module target flag?
    • node
      • Uhhhh but...that could change already does exist and changed.
      • Let's say it does change in the future - how do you opt into the old behavior?
      • Is there potential for shifting behavior to "bork" an existing program?
    • So node12 as well?
      • Should have these match.
    • What about a rolling node-esm flag that accumulates more?
      • node-next?
      • node14 could come out, etc. so node-next could be that rolling target.
      • Is there an official name?
        • No, it's just an update in the docs really.
        • Could ask for a name?
          • The name is there, it's Node 12 😄
  • Could module and moduleResolution be one flag?
    • module toggles a specific moduleResolution
    • Do we need a new moduleResolution flag?
      • Yeah.
  • Is node backwards-compatible?
    • Ehhh, they layer on the existing behavior.
    • But if you continue following the existing resolution rules (e.g. main field in package.json), you'll get the wrong behavior.
  • Kind of weird that package.jsons have more and more of our configuration.
  • Sounds like node12 for both
    • Eventually node-next or node-esm or something along those lines.
  • So "module": "node12" implies "moduleResolution": "node12".

Emit

  • Implementation strategy: don't want to ship in stable with a partial implementation - lots of moving parts.
  • What other things do we have to support?
    • .cjs
    • .mjs
    • Unfortunate reality in Node.
    • Potentially not used all that often, but users keep asking about them even though there's "type": "module".
      • Under that, we have a path forward for .ts -> .js which is still good.
    • But still need .mjs output. So .mts?
      • What about .mtsx?
        • What if you just have .mts?
          • .mts just supports JSX, doesn't support <AngleBracketCastSyntaxOn>values

          • Also type parameter lists with no constraint or trailing comma.

            const f = <T>(t: T) => {};
            
            // no good, have to rewrite as
            
            const f = <T extends unknown>() => {}
            const f = <T,>() => {}
          • What about .tsx for modules?

            • Well, doesn't generate an .mjs.
          • API isn't set up to disambiguate.

        • Feels bad to say "JSX is allowed in this file."
        • .mtx? 🤯
        • Supporting multiple extensions: we can do that, but we have special support include and exclude globs being specialized for TypeScript. Already got burned by this with JSON files.
        • How realistic would it be for us to say "no .mts and .cts"?
          • Probably for a bit, but we would inevitably get demand.
          • Still could start with something prescriptive. Maybe don't do it until we get an absolute need, along with a better sense of how people will organize their projects.
          • Our own experience: sometimes when you're in ESM fully, with "type": "module", you'll end up with times that you want to break out.
            • If you want to use native ESM with Electron, you need to break out and jump into CJS land to get require
            • Maybe .cts is more important than .mts.
            • Is there a way to say "this is CJS in a package.json?"
              • Nope.
              • You can put it in a sub-folder with a package.json that says "type": "whatever-is-not-module".
  • File extension madness! Can't imagine the cost of .cts, .cd.ts, etc.
    • We already use readDirectory, luckily it's not too bad anymore.
  • Luckily, a lot of resolution "just works" today but we need module disambiguation with modules.
  • We can start working on this, but we will not ship until we feel feature-complete. ✅

Performance

  • Our team has been working hard off thinking about how to help speed up TypeScript, and to help big projects scale.
  • Lots of anecdotes
  • One internal team switched from 1100 projects to way fewer. Hour-long compilation goes from 10 minutes.
  • Massive React projects that use project references.
  • One codebase used this huge set of path mappings - 1800 of them.
  • Normalizing slashes - one massive codebase does it 3 million times, 2 seconds total on its own, generates a ton of garbage
    • But MOST paths always have correct slashes, and on Unix they're ALWAYS the same.
    • Basically, just see if you can skip that work ahead of time.
  • Normalizing paths - removing relative intermediate components of paths.
  • Been using pprof
    • Basically the same info as the regular profiler, but its internal format actually allows you to handle longer profiling runs.
    • Also some visualizer properties.
    • Seems to have bugs on recursive functions though!
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label May 25, 2021
@Kingwl
Copy link
Contributor

Kingwl commented May 26, 2021

Our regex was wrong.

-- why we don't have regex type 🤷‍♂️

@DanielRosenwasser
Copy link
Member Author

Exactly.

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

2 participants