Design Meeting Notes, 6/4/2021

[DanielRosenwasser]

ES Modules in Node

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

• Last time we left off talking about .tsx syntax and how it affected JS module support.
  • .cjs and .mjs need a corresponding input format for them.
  • .cts and .mts
  • .jsx -> .tsx
  • .mjsx -> .mtsx?
    • Can potentially get away with just putting JSX in .mts.
    • Is .mjsx a thing?
    • No, probably an assumption that .mjs can contain JSX.
    • JSX is a superset of JS, right?
      • Yes but not a superset of TS.
      • In .js files we always parse JSX anyway.
        • We were trying to be "descriptive", not "prescriptive" - not something we're in love with.
• .cjs and .mjs
  • Have to start recognizing these as inputs under allowJs
  • Idea: in the new Node mode, we "do the right thing" - otherwise, we just assume they should be handled as regular .js files.
  • No .cjsx, .mjsx.
  • Do we conditionally parse JSX on whether the JSX flag is specified?
    • No, wouldn't start now either.
    • We just complain in grammar checks if you use JSX syntax without the flag.
• What is the distinction between .js and .jsx in today's implementation?
  • None.
• .cts and .mts extensions
  • These include TypeScript syntax and correspond exactly to .cjs and .mjs respectively.
  • That way we don't have to add a flag to say "emit as .cjs" and "emit as .mjs" from .ts input.
• How do we avoid .ctsx and .mtsx?
  • Can just assume .cts includes JSX, .mts includes JSX.
  • Would have to get rid of
    • Angle bracket type assertion syntax (<Type>expression)
      • Workaround: expression as Type
    • Arrow functions with single type parameters (<T>(x: T) => x)
      • Workaround: <T,>(x: T) => x or <T extends unknown>(x: T) => x
    • Infinite lookahead?
      • Already do infinite look-ahead in other places.
      • Could try parsing an arrow function following specific JSX opening tags.
        • Then error if you can successfully parse.
        • Feels like we can do the disambiguation.
        • But the > in the arrow is not illegal.
          • "Could've sworn that JSX rejected certain characters."
          • "Both major compilers just allowed them." 😕
        • What if you unsuccessfully parse?
          • You can reject the perfectly-written arrow functions, but imperfectly-written ones will get bad error messages.
  • Feels weird that you might try to rename your file and then get errors with no explanation.
    • Makes migration harder.
  • Would you use .cjs for React? It sounds like a Node-ism.
    • Electron?
  • Maybe worth checking with stewards of JSX (e.g. reach out to React team).
• Can always support .cts and .mts without JSX support and add it later.
  • But that means you have to reject the ambiguous syntax as well.
    • Otherwise you end up with the same issue of .ts syntax conflicting with JSX syntax.
  • let x = <Foo>yadda; - have to disallow this
  • let f = <T>(x: T) => x; - have to disallow this
  • But can always revisit and relax this!
• <T>3</T>
  • JSX Open, 3, LessThan, RegExp, Oops End-of-File
• Could consider a prologue directive like // @jsx: true
• Are we overthinking this based on arrow functions?
  • It's more common than you think!
  • https://stackoverflow.com/questions/32308370/what-is-the-syntax-for-typescript-arrow-functions-with-generics#comment99104831_45576880
  • https://stackoverflow.com/questions/41112313/how-to-use-generics-with-arrow-functions-in-typescript-jsx-with-react/41112882#41112882
• Prologue directives affecting parsing is not something our parser is wired up for.
  • We do these things post-parse.
  • TmLanguage grammars too!
    • Can't say "switch to TypeScript-React" right after.
    • Start-line headers? Something we can talk about with partner teams.
• Issue an error on and generic arrow functions?
  • Has the same downsides of the JSX variant from the start?
  • But future-proofed.
  • Gives us more direction, but doesn't fix the issue of .tsx -> .mts being weird...but works better for .ts -> .mts.
  • Editor support and command line tooling for helping the migration?
    • Sounds cool!
• Conclusion: .mts and .cts parsed as .ts, additional grammar error to inform people of what you meant if you wrote specific constructs.
• Declaration for .cjs, .mjs
  • .d.cts, .d.mts
  • We used to be scared of this because of the new resolution rules, but now we read directory contents ahead of time to see whether a file read will succeed.
  • We would have to have separate shapes for different modules depending on how it's imported.
  • You only need to look for .d.mts if you import with an .mjs extension, right?
    • Yes.
• Something worth thinking as a follow-up:
  • JSON: .d.tson?
  • Extension priorities will add a lot of complexity and work.

[Airkro]

• mjs/cjs is for node.js only, not for browsers or deno
• commonjs never be a part of ECMAScript, not supported in browsers
• mjs in node.js have some behavior not support in browsers, it's not pure ECMAScript
• most of the use-case of JSX is for html in browser

So, I think there is no need to support JSX in mjs/cjs

---

I'm not a team member, I guess this issue is comment allowed, let me know if it's not, I'll delete this.

[fatcerberus]

mjs in node.js have some behavior not support in browsers, it's not pure ECMAScript

Can you clarify on this point? Browsers don't care about file extensions (only mimetypes), and IIRC module specifier resolution is implementation-defined per ECMAScript. I don't think there's anything non-standard there?

[Airkro]

@fatcerberus

Try to say it clear, I mean the code might be an ECMAScript-module, but it doesn't mean they have the same implementation:

// this line won't work in the browser
import fs from 'node:fs/promises';

// this line won't work in node.js
import func from 'http://example.org/test.js';

For a long time, we don't know *.js is ready for who, browser or node.js
But now we know *.mjs/*.cjs is for node.js only.

[Airkro]

I thought JSX is a sugar designed to make HTML binding easier, it's for browser only.

But now I realize JSX is used in many SSR projects. run them in node.js is possible, I should change my mind.

[BenBeattieHood]

Has there been any further decision on the adoption of an .mtsx extension?

[GoToLoop]

I'd love for TS to recognize both ".mtsx" & ".ctsx" file extensions!
Possibly emit them as ".mjsx" & ".cjsx" respectively.

[yinzara]

There is still no way now more than 2 years after this discussion to indicate in a CommonJS React project that a specific file is a TypeScript MJS module making it impossible in a TypeScript CJS application to use any ESM only dependency which now means react-dnd (the primary drag and drop utility) is no longer accessible to the majority of ReactJS apps as it has gone ESM only (ARGGGGGGGGG WHY!!!!!).

I am forced to use a .mjs file and completely remove all typing from my file and then use a combination of Suspense and Lazy to load it as a component in a CJS file.

[EvanLovely]

There is still no way now more than 2 years after this discussion to indicate in a CommonJS React project that a specific file is a TypeScript MJS module

Wish there was a solution here; anybody have one?