搜索词
--build --module --outDir
建议
我希望能够在 --build 模式下传递 --module 和 --outDir,这样我就可以在不需要多个 tsconfig 文件的情况下为不同的构建输出设置多个 npm 脚本。
用例
在 Aurelia vNext 中，我们已经完全采用了新的 3.0 构建系统，并开始准备发布。我们希望发布所有不同模块系统的构建输出(适用于所有包),以便消费者可以轻松指向与他们的项目兼容的那个。
在 3.0 之前，我们可以这样做：
"build:commonjs": "tsc -m commonjs --outDir dist/commonjs",
"build:amd": "tsc -m amd --outDir dist/amd",
"build:system": "tsc -m system --outDir dist/system",
"build:umd": "tsc -m umd --outDir dist/umd",
"build:es2015": "tsc -m es2015 --outDir dist/es2015",现在尝试这样做时，它不起作用：
"build:commonjs": "tsc -b -m commonjs --outDir dist/commonjs",
"build:amd": "tsc -b -m amd --outDir dist/amd",
"build:system": "tsc -b -m system --outDir dist/system",
"build:umd": "tsc -b -m umd --outDir dist/umd",
"build:es2015": "tsc -b -m es2015 --outDir dist/es2015",
"build:esnext": "tsc -b -m esnext --outDir dist/esnext",结果是：
message TS6096: File (...)/packages/runtime/-m' does not exist
message TS6096: File (...)/packages/runtime/commonjs' does not exist然后什么都没有发生。我在文档中读到，只有与 --build 结合使用的 4 个特定标志是受支持的，所以这似乎没有实现。
示例
我们希望在 package.json 中有一个这样的配置：
"build:commonjs": "tsc -b -m commonjs --outDir dist/commonjs",
"build:amd": "tsc -b -m amd --outDir dist/amd",
"build:system": "tsc -b -m system --outDir dist/system",
"build:umd": "tsc -b -m umd --outDir dist/umd",
"build:es2015": "tsc -b -m es2015 --outDir dist/es2015",
"build:esnext": "tsc -b -m esnext --outDir dist/esnext",
"build": "run-p build:*",当从顶级包(使用 lerna...)调用 npm run build 时，它将在所有模块格式中为所有包生成构建输出
检查清单
我的建议满足以下准则：
- 这不会对现有的 TypeScript / JavaScript 代码造成破坏性更改
- 这不会改变现有 JavaScript 代码的运行时行为
- 这可以在不根据表达式的类型发出不同的 JS 的情况下实现
- 这不是一个运行时特性(例如新的表达式级语法)
7条答案
按热度按时间n6lpvg4x1#
我的理解是，这些标志应该由每个引用的项目(在tsconfig中)设置。考虑一个引入多个模块的构建，没有意义有一个(全局)CLI选项。
ecbunoof2#
对于一个示例设置，您需要查看 the Aurelia Monorepo 。我们需要使用单个命令构建许多软件包，所有这些软件包都需要输出每种格式。每个软件包都有相同的配置，但现在我们不得不在各个地方复制大量的 tsconfig.files,数量为6 * NumberOfPackages。在我们的情况下，这是36+个 tsconfig 文件而不是6个。每次我们向我们的monorepo添加一个新软件包时，我们必须添加6个副本。这对于实际的monorepo设置中的维护并不好。
50pmv0ei3#
在每个包有多个模块输出的情况下，将此设置在tsconfig中与将其设置在cli标志中之间没有功能差异。
示例设置
考虑具有两个包
package-foo和package-bar的场景，以及两个不同的模块输出commonjs和amdpackage-footsconfig.json说"module": "commonjs"tsconfig.amd.json说"module": "amd"package.json说"main": "dist/commonjs/index"package-barpackage-foo构建步骤
现在我们在
package-bar中运行tsc -b,会发生以下情况：package-bar看到对package-foo的依赖关系package-foo被构建；输出到package-foo/dist/commonjspackage-bar被构建，引用package-foo/dist/commonjs;输出到package-bar/dist/commonjs然后我们在
package-bar中运行tsb -b tsconfig.amd.json,会发生以下情况：package-bar看到对package-foo的依赖关系package-foo被构建；输出到package-foo/dist/commonjspackage-bar被构建，引用package-foo/dist/commonjs;输出到package-bar/dist/amd结果
package-bar现在一切正常。输出没有合并，因此使用package-foo的 commonjs 构建输出来生成package-bar的 AMD 输出并不会以任何方式引起注意。在下一个顺序步骤中，我们以相同的方式构建
package-foo,现在我们为两个包都有了模块输出。问题解决了。需要非默认模块输出的消费者通常需要通过我们的cli进行安装/配置，这可以确保 所有包都引用相同的模块输出。
可以通过将cli参数传递给
tsc -b以实现相同的效果。jtjikinw4#
Related to #25613
wh6knrhe5#
@RyanCavanaugh ,如果这能让你们更轻松的话，我会同意将此问题关闭为#25613的重复。基本上，我的问题与同样的事情有关，只是针对某些特定的标志。由你们决定
9o685dep6#
感谢fkleuver -我认为这些应该单独作为问题，因为"混合"模式可能会自然地排除每个项目计算的事物，如outdir和rootdir。这种情况足够复杂，值得拥有自己的行为。
ctehm74n7#
请注意，我遇到了相同的问题：
AVA只能处理运行测试所需的那种格式。webpack,在测试之后进行捆绑时，文件应该使用ECMAScript模块，因为在那里有更多的优势。现在当我运行
tsc -b,运行我的单元测试并在此之后执行tsc -b tsconfig.esm.json以进行webpack构建时，由于我没有修改任何文件，因此输出目录中的内容没有发生变化，类型声明保持不变。作为解决方法，我可以引入两个不同的输出目录。一个用于ESM,另一个用于CommonJS,但这感觉有点hacky。或者，就像我现在所做的那样，完全忽略ESM,而是始终编译为CommonJS。