英文:
How to use `tsconfig.js` file instead of `tsconfig.json`
问题
我有多个项目,每个项目都有多个tsconfig.json
文件(以及其他配置文件),我的目标是在每个项目中都使用相同的配置。
为了实现这个目标,我决定创建一个npm包config
,其中包含一个标准的tsconfig.json
文件(以及其他.json
配置文件)。
我之前使用的TypeScript构建命令是tsc -p tsconfig.json --incremental
,我尝试将其更改为tsc -p tsconfig.js --incremental
,并使用一个类似如下的tsconfig.js
文件:
module.exports = {
...require('./node_modules/@myOrg/myPackage/tsconfig.json')
};
在这里使用了扩展运算符,以便在需要时可以覆盖一些属性。
我的想法似乎是合理的,但它不起作用,因为它在使用这个配置文件时不会编译每个tsconfig.json
的属性(例如esModuleInterop
、downlevelIteration
、es2015
等),而这些属性显然在包的tsconfig.json
中。
如何实现我的目标?也许这种技术对于除tsconfig.json
之外的其他.json
配置文件都有效,因为其中一些标志是必需的,以使其成为可能。
英文:
I have multiple projects with multiple tsconfig.json
files (and other config files) and my goals is to use the same in each projects.
To achieve that I decided to create a npm package config
, with a standard tsconfig.json
file (and other .json
config files).
my previous typescript's command in order to build my project were tsc -p tsconfig.json --incremental
and I tried to change it to tsc -p tsconfig.js --incremental
with a tsconfig.js
file looking like:
module.exports = {
...require('./node_modules/@myOrg/myPackage/tsconfig.json')
};
Using spread where I could override some properties if needed.
My idea seems to be legit but it doesn't works, it doesn't compile using tsc with this config file because it omit each tsconfig.json's properties (such as esModuleInterop
, downlevelIteration
, es2015
, etc...) which are obviously in the package's tsconfig.json
.
How can I achieve my goal ? may this technique works for every other .json
config file except tsconfig.json
because some of it's flags are required to make it possible
答案1
得分: 3
可执行的配置模块明确不受支持:
我们不接受将配置变成可执行内容的 PR。这会引发一系列棘手的问题(是否安全运行此配置?配置文件有什么依赖关系?配置文件对其环境做出了什么假设?),我们更愿意保持关闭状态。
备选方案:
您尚未说明_为什么_要将您的 tsconfig 集中。如果只是为了方便,那么您可以使用 extends
选项从另一个 tsconfig 文件继承配置选项。
请注意,"配置文件中找到的所有相对路径都将相对于其所在的配置文件解析。" 因此,采用这种方法可能会阻止您继承_所有_属性。您可能需要在本地配置文件中提供至少一些选项(如 files
)。
如果您真的想要整体复制您的 tsconfig(包括相对文件路径),那么可以使用构建工具(如 gulp)将 tsconfig.json 从已知位置复制到项目根目录,然后运行 tsc
。我相信您可以想象到这将引入一些问题,包括要求开发人员在在编辑器如 VS Code 中加载项目之前执行额外的 CLI 步骤。
警告:
基础配置对于标准化构建非常有用,但存在引发比解决更多问题的风险。保持平衡非常重要。从外部来源继承_过多_内容会使项目僵化,难以适应环境变化或新技术。您可能会发现自己需要为一个项目的缘故调整基础配置,但这些调整可能与其他项目不兼容。或者您可能会发现自己不断覆盖基础配置中的相同属性,因为您的偏好发生了变化,但旧项目仍然依赖于这些旧选项。您可能可以通过版本化或标记来解决这个问题,但那样又有什么好处呢?您仍然有多个配置,只是更难找到和使用。将项目配置与项目一起保留是有充分理由的。
从通用配置继承并非一无是处,但我认为过分依赖继承将引发长期问题,难以解决,而不仅仅是从模板复制您的 tsconfig。
英文:
An executable config module is explicitly not supported:
> We are not accepting PRs to turn config into an executable thing. This opens up an enormous can of worms (is it safe to run this? what dependencies does the config file have? what does the config file assume about its environment?) that we'd prefer remain closed.
>
> GitHub: Allow javascript (or typescript) config file <Suggestion> (#30400)
Alternatives:
You haven't said why you are centralizing your tsconfig. If it's just for convenience, then you could just use the extends
option to inherit configuration options from another tsconfig file.
Note that "All relative paths found in the configuration file will be resolved relative to the configuration file they originated in." So, following this approach would likely prevent you from inheriting all properties. You'd probably need to supply at least a few options in your local config file (such as files
).
If you really want to copy your tsconfig wholesale (including relative file paths), then you could use a build tool (like gulp) to copy the tsconfig.json from a well-known location to your project root before running tsc
. I'm sure you can imagine some of the problems this would introduce, including requiring a developer to perform extra CLI steps before loading the project in an editor like VS Code.
A word of caution:
A base config can be very useful for standardizing your builds, but there's a risk you will cause more problems than you solve over the long-term. It's important to strike a balance. Inheriting too much from an outside source will stiffen your project, making it difficult to adapt to environmental changes or new technologies. You may find yourself needing to adjust the base configuration for the sake of one project, but those adjustments may be incompatible with another. Or your may find yourself constantly overriding the same properties from your base configuration because your preferences changed but older projects still depend on those old options. You might get around this by versioning or tagging, but then what have you gained? You still have more than one config, they're just harder to find and use. There are good reasons to keep your project configuration with your project.
Inheriting from a common config isn't necessarily all bad, but over-dependence on inheritance will, in my opinion, cause long-term issues that are harder to address than just copying your tsconfig from a template.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论