import cjs from "cjs" 和 require(esm) 的选项

#54102

• 有两个选项
• 选项1: moduleFormatInterop - --moduleFormatInterop (all names bikesheddable) #58480
• 选项2: defaultIsModuleExports 和 allowRequireESM - --defaultIsModuleExports and --allowRequireESM  #58526
• 激励示例是什么？

// package.json
{
    "type": "module"
}

// index.js
import pkg from "./vendor/pkg/index.js";
console.log(pkg);

// vendor/pkg/index.js
module.exports.__esModule = true;
module.exports.default = "pkg";

• 所以这里有分歧。
• 许多打包器都说这只是将字符串 pkg 输出到控制台。
• esbuild 和 Webpack 通过将整个 vendor/pkg/index.js 作为 default 导入来实现“特定于Node”的行为，并且它本身是一个具有 default 属性的对象。因此，它会记录 [Object object] 或 { __esModule: true, default: "pkg" }。
• 此外，Webpack 在JavaScript和TypeScript之间的行为也有所不同。
• Rollup 使这一切都可以根据构建进行配置，并使用名为 defaultIsModuleExports 的标志来控制从“cjs”导入 cjs 的行为。
• 这是我们在选项2中使用的选项名称。
• 我们不喜欢什么？
• 目前还不清楚这会产生多大影响 - 没有太多React，相关的链接问题似乎无关紧要。
• 但是，如果您正在捆绑，您可能不会遇到这个问题，因为 "type": "module" 通常没有指定(或者人们不使用 .mts )。
• 我们甚至告诉人们不要打开它，因为打包器的行为不同。
• 可以稍微澄清一下代码是如何进入这个状态的。
• 还有关于复杂性的担忧 - 更多的标志。
• 此外，可发现性 - 如何知道需要设置它？
• 此外，许多库在捆绑器中解析为 ESM,但类型没有指示这一点。
• 如果可以提供更好的错误消息，说明“如果您真的想这样做，您需要这个标志”，那就更好了。
• 可以想象这只是对更大模块标志的一个更细粒度的标志，该标志指定了特定行为用于 esbuild、swc 等。
• 如果我们有一个计划在那里，也许我们会觉得这样做更好。
• 如果我们采取相反的立场 - 让这些打开，人们需要关闭这些标志呢？
• 可以说，每个打包器都试图与 Node 对齐，所以节点打包器行为感觉就像人们想要的那样，对吧？
• 我们很难完全说服自己。例如，Bun决定不采用 esbuild/webpack 行为，所以也许并不像我们希望的那样明确。
• 我们想推迟这个讨论 - 既等待更多反馈，也想了解原始场景是如何被触发的。

检查字符串字面量联合对象键和模板类型

#58673

• 计算属性的联合类型会被压缩成一个字符串索引签名。
• 可以想象 { [... as "x" | "y"]: string } 应该等同于 { x: string } | { y: string } 。
• 那关于模板类型呢？
• { [... asfoo${string}]: string } - 这应该等同于 { [props:foo${string}]: string } 吗？
• Uhhh.
• 可以说，你最终得到一个过于宽松的对象时，你不太可能想要获得索引签名。
• 只有通过 noUncheckedIndexedAccess 才能解决这个问题。
• 从另一个Angular 看，你说每个常量值都会为索引获得唯一的类型。
• 有几种不同的处理方式。

declare const xy: "x" | "y";

const x1 = {
    [xy]: 123,
};

// could be

const x1: { [props: string]: number }; // today's behavior

// or

const x1: { x: number } | { y: number };

// or

const x1: { x?: number, y?: number };

// or

const x1: { x: number, y?: number } | { x?: number, y: number };

// or something where where an index signature actually acts differently,
// defers some of its computation for different behavior of reading/writing.

const x1: { [props: "x" | "y"]: number };

• 今天，最后一个示例只是由于字面类型糖化为单个属性而解糖化为 { x: number, y: number } 。
• 这在很大程度上与Map类型的行为相一致。
• 还有重叠等问题，但我们有索引签名适用规则，所以也许还有其他的东西在这里。