禁止在 Nrwl Nx 的同一库中导入桶文件答案

【问题标题】：Disallow barrel file imports within the same library in Nrwl Nx禁止在 Nrwl Nx 的同一库中导入桶文件
【发布时间】：2020-05-28 03:54:45
【问题描述】：

假设我们在Nrwl Nx 中有一个应用程序和一个库。

/apps
  /myApp

/libs
  /myLib
    /components
       /my.component.ts
       /other.component.ts
    /index.ts

我已经在nx.json 和nx-enforce-module-boundaries 规则中设置了标签来阻止在lib 中导入应用程序。它可以工作，这部分很好。

我想做的另一件事是在库中强制使用桶文件。所以我在tsconfig.ts创建了一个路径

"paths": {
   "@myNs/my-lib": ["libs/myLib/index.ts"]
}

我遇到了这个问题。假设我们从index.ts 导出了一些东西。

// index.ts
export { MyComponent } from './components/my.component';

现在，如果我们使用一些自动导入 IDE 功能（例如来自 WebStorm 或 VS Code）。他们将使用路径@myNs/my-lib 导入MyComponent - 这是意料之中的，因为我刚刚这样配置它。

当我想在 myLib 中自动导入某些东西时，出现了一个真正的问题（这些导入应该是相对的，而不是 @myNs/my-lib） - 根据逻辑和这篇文章 ([Interesting article here])：

永远不要让 lib 从其自己的 Barrel 文件中导入

特定库中的 TypeScript 模块不应该关心什么 lib 暴露的功能，所以它不应该使用自己的桶随时存档。

如果一个模块从它自己的桶文件中导入一些东西，它几乎总是导致循环引用错误。因此，从进口模块内部应使用相对路径导入。

所以我找到了一种解决方法来阻止 lib 中的 TS 路径式导入。我在libs/myLib/tslint.json里面加了一条规则：

"rules": {
   "import-blacklist": [true, "@myNs/my-lib"]
}

无论如何，它并没有修复自动导入功能，只是不允许在库中使用错误的导入。

另一个问题是仍然允许错误的导入。假设OtherComponent要导入MyComponent 那么有三种可能：

import { MyComponent } from './my.component'; // the correct way
import { MyComponent } from '.'; // not the best, but also the correct way
import { MyComponent } from '..'; // using barrel file - not correct (look at the citation above), but still successfuly validated by TSLint

问题：

如何禁止在同一个库中导入桶文件？
如何将 IDE 配置为在 lib 内部具有相对路径，在外部具有 TypeScript 路径 (@myNs/my-lib)？

【问题讨论】：

在 设置 |编辑 |代码风格 | TypeScript，Imports，尝试将 Use path mappings from tsconfig.json 设置为 Only in the files outside the specified paths - 它会让事情变得更好吗？
刚才试过这个，但对我来说，它的行为与 "Always" 选项相同。我什至尝试重新启动 WebStorm 并清除缓存。

标签： angular visual-studio-code webstorm tslint nrwl

【解决方案1】：

这是 IntelliJ 中的设置。我在 v2020.1 中看到这项工作正常。

我喜欢 @Nickson 创建的规则，并认为添加以防止错误是个好主意！

【讨论】：

设置后，在某些情况下，IntelliJ 仍然从 '..' 导入。我需要将 ',..' 附加到Do not import exactly from。

【解决方案2】：

没有人回答，所以我决定创建一个简单的TSLint 规则来处理这种情况：import-blacklist-extended

规则在Nrwl monorepo 中运行良好，但它可以被优化并且可以更好地解决一些机制。如果您需要任何更改，请随时在 Github 上创建问题和 PR。

【讨论】：