Skip to content

Design Meeting Notes, 8/4/2023 #55271

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

Closed
DanielRosenwasser opened this issue Aug 4, 2023 · 2 comments
Closed

Design Meeting Notes, 8/4/2023 #55271

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

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Aug 4, 2023

What Does --module Mean?

#55221

// src/index.ts
import dep from "./dep";

console.log(dep);
console.log(dep.toUpperCase());
// src/dep.js
Object.defineProperty(exports, "__esModule", { value: true });
exports.default = "my default export!";
// tsconfig.json
{
    "compilerOptions": {
        "module": "esnext",
        "moduleResolution": "bundler"
    }
}
  • Tends to work with most bundlers, TypeScript thinks this is fine.
  • Change to index.mts, TypeScript is still fine with this; but most bundlers will change their behavior and you'll get a runtime error.
    • console.log(import_dep.default.toUpperCase())
                                     ^
      TypeError: import_dep.default.toUpperCase is not a function
      
  • --module esnext is not adequate to describe behaviors.
  • So what does the module flag mean? Two competing definitions:
    1. Purely, what output syntax do you want?
    2. How is this module going to get understood by a runtime or bundler?
  • Does --verbatimModuleSyntax true guide us at all?
    • Not exactly.
  • moduleResolution affecting module format is a big part of the issue here.
  • We are simultaneously not robust enough to model every environment, but also too robust to model every behavior.
  • Could we ship those advanced options as well-known target environments?
    • Some of these runtimes and bundlers ship so often that...can we?
  • What is a "web" environment? Tie it to a year?
    • Isn't that --module esnext?
      • No, no way to disallow CJS and the like.
  • Related to "how do these old modes understand new file extensions?" and the like.
  • Could imagine a change where in all modes we start respecting the module format a lot more strictly.
    • Something that resolves to ESM from CJS should error under the node10 mode.
  • If we had a world where ESM files would stop emitting to CJS - do we have an appetite for that? Without waiting until 6.0 or something like that?
    • Well today what happens if you punt all projects from node10 to node16?
    • A bunch of issues with incorrect resolutions. 🎭
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Aug 4, 2023
@fatcerberus
Copy link

If we had a world where ESM files would stop emitting to CJS

Isn’t that what verbatimModuleSyntax does?

@andrewbranch
Copy link
Member

It doesn’t prevent you from writing import foo = require("mod") in a .mts file in --module commonjs. All it sees is that you wrote CJS syntax in a module format that’s going to emit CJS, so you’re good. Nothing cares about the file extension in --module commonjs, which is the problem.

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

4 participants