防止在Typescript中导入不当并强制执行项目层次结构 [英] Preventing inappropriate imports and enforcing project hierarchy in Typescript

问题描述

在TS项目中，我希望阻止以下内容:

In a TS project I'd like the following to be blocked:

• 通常从文件夹projectA导入的文件夹中的文件
• 文件夹projectB中的文件从文件夹projectA中导入

我希望允许以下内容:

• 来自文件夹projectA的文件从文件夹projectA导入
• 文件夹项目中的文件从公用文件夹导入.

我知道参考文献.但是，据我了解，它们需要一种用于类型检查的构建程序(如果进行了这种分离，则必须先构建以创建d.ts文件)，而我宁愿避免这种情况.

I'm aware of References. However, as I understand, they require a build for type checking (If such a separation is made, one must build to create d.ts files first) which I'd rather avoid.

我有什么选择?是否可以通过单独的tsconfig文件为每个项目/文件夹简单地实现?

What options do I have? Is it possible to achieve simply via separate tsconfig files for each of those projects/folders?

推荐答案

TLDR;您真的应该只使用引用.这正是他们的目的.

但是让我们先解决您的一些具体想法:

TLDR; You really should just use References. It is exactly what they are for.

But let's address some of your specific thoughts first:

1. 是否可以通过单独的tsconfig文件为每个项目/文件夹简单地实现?

是的，但是不是很灵活.您可以通过将 common 设置为.来隔离它.如果尝试将 projectA 导入到 common 中，则将出现'/path/to/projectA' is not under 'rootDir'错误.但是要能够将 common 导入到 projectA 中，它的rootDir必须更具全局性，但这将允许您导入 projectB .

Yes, but it's not very flexible. You could isolate common by setting its rootDir to .. You would then get an '/path/to/projectA' is not under 'rootDir' error if you tried to import projectA into common. But to be able to import common into projectA, its rootDir would have to be more global, but then that would allow you to import projectB.

不仅如此，根据项目参考文档:

以前，如果使用单个tsconfig文件，则无法使用此结构:

Previously, this structure was rather awkward to work with if you used a single tsconfig file:

• 实施文件可以导入测试文件
• 如果没有在输出文件夹名称中出现src的情况，则不可能同时构建test和src，这可能是您不希望的
• 仅更改实现文件中的内部，就需要再次进行 typechecking 测试，即使这绝不会导致新的错误
• 仅更改测试就需要再次对实现进行类型检查，即使没有任何更改

  ---

• It was possible for the implementation files to import the test files
• It wasn’t possible to build test and src at the same time without having src appear in the output folder name, which you probably don’t want
• Changing just the internals in the implementation files required typechecking the tests again, even though this wouldn’t ever cause new errors
• Changing just the tests required typechecking the implementation again, even if nothing changed

  ---

您可以使用多个tsconfig文件解决这些问题中的 一些 ，但会出现新问题:

You could use multiple tsconfig files to solve some of those problems, but new ones would appear:

• 没有内置的最新检查功能，因此您总是总是运行两次tsc
• 两次调用tsc会导致更多的启动时间开销
• tsc -w不能一次在多个配置文件上运行

• There’s no built-in up-to-date checking, so you end up always running tsc twice
• Invoking tsc twice incurs more startup time overhead
• tsc -w can’t run on multiple config files at once

我知道参考文献.但是，据我了解，它们需要一种用于类型检查的构建程序(如果进行了这种分离，则必须先构建以创建d.ts文件).

发生这种厌恶的原因是什么?

What's the reason for this aversion?

• 如果这是构建新项目克隆的前期成本，那么这将由改善的构建时间所弥补(请参阅下面的自变量).后者对开发人员生产力的好处将远远超过前者的成本.

• If it's the upfront cost of building a fresh project clone, that will be more than made up for by the improved build times (see arguments for below). The benefits of the latter for developer productivity will far outweigh the costs of the former.

具有讽刺意味的是，您对前期成本的关注越大，那么改进的构建时间所带来的收益就越大！

Ironically, the larger you concern about the upfront cost, the larger the benefit from the improved build times!

如果您希望能够在无需构建的情况下使用VS Code或WebStorm这样的类型和链接感知编辑器来导航新克隆，则可以通过将.d.ts文件检入源代码控制中来实现此目的.

If it's that you want to be able to navigate a fresh clone in a type and linkage aware editor like VS Code or WebStorm without having to build, you can achieve this by checking the .d.ts files into source control.

这是文档专门说的:

由于依赖项目使用了根据其依赖关系构建的.d.ts文件，因此您必须检入某些构建输出或在克隆项目后构建一个项目，然后才能浏览在编辑器中进行项目，而不会看到虚假错误.我们正在努力开发一种幕后.d.ts生成过程，该过程应能够缓解这种情况，但目前，我们建议告知开发人员克隆后应该进行构建.

Because dependent projects make use of .d.ts files that are built from their dependencies, you’ll either have to check in certain build outputs or build a project after cloning it before you can navigate the project in an editor without seeing spurious errors. We’re working on a behind-the-scenes .d.ts generation process that should be able to mitigate this, but for now we recommend informing developers that they should build after cloning.

项目参考的论点

从文档中

The argument for Project References

From the docs:

• 您可以大大缩短构建时间

• you can greatly improve build times

期待已久的功能是用于TypeScript项目的智能增量构建.在3.0中，可以将--build标志与tsc一起使用.实际上，这是tsc的新入口点，其行为更像是构建协调器，而不是简单的编译器.

A long-awaited feature is smart incremental builds for TypeScript projects. In 3.0 you can use the --buildflag with tsc. This is effectively a new entry point for tsc that behaves more like a build orchestrator than a simple compiler.

运行tsc --build(简称为tsc -b)将执行以下操作:

Running tsc --build (tsc -b for short) will do the following:

• 找到所有引用的项目
• 检测是否为最新
• 以正确的顺序构建过时的项目

  ---

• Find all referenced projects
• Detect if they are up-to-date
• Build out-of-date projects in the correct order

  ---

不必担心在命令行上传递的文件的顺序-tsc会在需要时对它们进行重新排序，以便始终先构建依赖项.

Don’t worry about ordering the files you pass on the commandline - tsc will re-order them if needed so that dependencies are always built first.

加强组件之间的逻辑分离

以新的更好的方式组织代码.

organize your code in new and better ways.

项目参考文档中还有一些更有用的好处/功能. .

There's some more useful benefits / features in the Project References doc.

• src/tsconfig.json

• src/tsconfig.json

即使您在根目录下没有代码，此tsconfig也可以位于 所有常用的设置都可以使用(其他设置将继承自该设置)，并且 这将使一个简单的tsc --build src可以构建整个 项目(并使用--force从头开始构建它).

Even if you have no code at the root, this tsconfig can be where all the common settings go (the others will inherit from it), and it will enable a simple tsc --build src to build the whole project (and with --force to build it from scratch).

{
  "compilerOptions": {
    "rootDir": ".",
    "outDir": "../build",
    "composite": true
  },
  // this root project has no source of its own
  "files": [],
  // but building this project will build all of the following:
  "references": [  
    { "path": "./common" }
    { "path": "./projectA" }
    { "path": "./projectB" }
  ]
}

• src/common/tsconfig.json

  • src/common/tsconfig.json

    由于 common 没有引用，因此导入仅限于其目录和npm_modules中的目标.我相信，您甚至可以通过赋予它自己的package.json来限制后者.

    Because common has no references, imports are limited to targets within its directory and npm_modules. You could even restrict the latter, I believe, by giving it its own package.json.

        {
         "compilerOptions": {
            "rootDir": ".",
            "outDir": "../../build/common",
            "composite": true
          }
        }
    

  • src/projectA/tsconfig.json

  • src/projectA/tsconfig.json

    projectA 可以导入 common .

        {
          "compilerOptions": {
            "rootDir": ".",
            "outDir": "../../build/projectA",
            "composite": true
          },
          "references": [
            { "path": "../common" }
          ]
        }
    

  • src/projectB/tsconfig.json

  • src/projectB/tsconfig.json

    projectB 可以导入 common 和 projectA .

        {
          "compilerOptions": {
            "rootDir": ".",
            "outDir": "../../build/projectB",
            "composite": true
          },
          "references": [
            { "path": "../common" }
            { "path": "../projectA" }
          ]
        }
    

  这些只是一些示例.我在下面使用tsc开关的缩写形式，例如-b而不是--build.从仓库根目录执行的所有命令.

  These are just some examples. I use the abbreviate forms of tsc switches below, e.g. -b instead of --build. All commands executed from the repo root.

  tsc -b src-构建整个树.

  tsc -p src/projectA/仅编译projectA.

  tsc -p src/projectA/ compiles just projectA.

  tsc -b src/projectA/构建projectA和所有过时的依赖项.

  tsc -b src/projectA/ builds projectA and any dependencies that are out of date.

  tsc -b -w src-生成&看整棵树.

  tsc -b -w src - build & watch the entire tree.

  tsc -b --clean src-删除整个树的输出.

  tsc -b --clean src - delete the output for the entire tree.

  tsc -b -f src-强制重建整个树.

  使用-d或-dry开关可预览tsc -b的功能.

  Use the -d or -dry switch to get a preview of what tsc -b will do.

  这篇关于防止在Typescript中导入不当并强制执行项目层次结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！