Tslint: no-implicit-dependencies:支持路径映射

创建于 2017-10-20  ·  18评论  ·  资料来源: palantir/tslint

错误报告

  • __TSLint 版本__:5.8.0
  • __TypeScript 版本__:2.7.0-dev.20171020
  • __通过__运行TSLint:CLI

正在整理 TypeScript 代码

源代码/ a.ts

import { x } from "foo";

类型/食物.d.ts

export const x = 0;

配置文件

{
    "compilerOptions": {
        "paths": {
            "*": "types/*"
        }
    }
}

使用tslint.json配置:

{
    "rules": {
        "no-implicit-dependencies": true
    }
}

实际行为

ERROR: /home/andy/sample/tslint/src/a.ts[1, 19]: Module 'foo' is not listed as dependency in package.json

预期行为

没有错误。 我认为如果导入未解析为node_modules某些内容,则此规则应忽略它。

最有用的评论

当我们为自己的源代码使用别名时(不是从 npm 包导入),此规则不起作用。 使用绝对路径而不是相对路径非常有用。
在我们的 tsconfig.json 中,对于 angular 应用程序,我们只需添加:

"compilerOptions": {
  ...
  "baseUrl": "./src",
  "paths": {
    "~/env": ["environments/environment"],
    "~/*": ["app/*"]
  }
}

然后我们可以像这样导入:

import {FooService} from '~/core';
import {Environment} from '~/env';

可能我们应该重新打开这个问题来解决这种情况(不需要 node_modules,只需要 tsconfig.json 文件)。
我很欣赏这条规则,所以很遗憾禁用它。

所有18条评论

我认为如果导入未解析为 node_modules 中的某些内容,则此规则应忽略它。

该规则不会尝试解析模块。 这意味着您需要安装所有依赖项,这对于 peerDependencies 和 optionalDependencies 是不可能的。 使用当前的实现,您可以在不安装任何东西的情况下 lint 一个新的克隆。 我想这就是大多数代码质量工具所做的。

据我了解路径映射,它们只存在于编译时。 在运行时,您仍然需要为 node/webpack/whatever 安装模块才能正确选择它。
这意味着路径映射仅在编译期间忽略的仅类型导入时才相关。 在这种情况下,规则可能不是您的正确选择。

在我们的例子中,通常根本没有package.json ,所以我想我们应该禁用这个规则。 谢谢!

就我而言,我正在使用路径映射“导入”我正在同时处理的单独打字稿项目:

"compilerOptions": {
    ...
    "paths": {
        "tsbase": ["../tsBaseProject/src"],
        "tslibrary": ["../tsProjectLibrary/src"]
    }
}

这样我就可以在项目中使用它们,就好像它们是模块一样。
有没有办法将它们列入白名单?

@marcoqu路径映射仅在编译时相关。 在运行时,这些模块需要存在于 node_modules 中。 我建议将它们作为dependenciespeerDependencies到您的 package.json

当我编译“导入”辅助项目的主要源代码时,所有内容都被编译成一个包,就好像它们是项目中的实际文件夹一样。 我不需要将它们放在 node_modules 文件夹中。
需要明确的是,在辅助项目文件夹中,我有实际的 .ts 文件,而不仅仅是类型声明。

+1 用于在 no-submodule-imports 中添加白名单

我们也有这样的情况,我们使用我们定义基本目录的路径别名“~”以避免相对导入的情况。 这个别名后来被 webpack、fuse-box 等解决了。从 5.8 开始,tslint 因为这个原因吐出很多虚假错误......

他说的^^

升级后,由于上述相同的原因,我现在有数百个这样的错误。 一种毫无意义的规则。

当我们为自己的源代码使用别名时(不是从 npm 包导入),此规则不起作用。 使用绝对路径而不是相对路径非常有用。
在我们的 tsconfig.json 中,对于 angular 应用程序,我们只需添加:

"compilerOptions": {
  ...
  "baseUrl": "./src",
  "paths": {
    "~/env": ["environments/environment"],
    "~/*": ["app/*"]
  }
}

然后我们可以像这样导入:

import {FooService} from '~/core';
import {Environment} from '~/env';

可能我们应该重新打开这个问题来解决这种情况(不需要 node_modules,只需要 tsconfig.json 文件)。
我很欣赏这条规则,所以很遗憾禁用它。

@andy-ms 请重新考虑支持路径(我们将它广泛用于 nx 工作区)。 这是一个非常有用的规则,但现在我被迫禁用它。

我尝试查看源代码并修复需要沿着这些线的某个地方。 我还检查了 Typescript 是如何处理它的,并将其追溯到这个函数。 复制这种逻辑绝对不是一件容易的事。 我不确定该函数是否可以重用,有一堆我不确定的参数。

我也非常希望看到这个问题得到解决。 路径映射是一个非常有价值的功能。 我还尝试使用链接模块作为解决方法,但也不支持这些模块。

我确实想出了一种解决方法,可以在一定程度上解决我的问题,但不确定它是否适用于每个人,或者它是否可以维护。 无论如何,解决方案如下:

使用tsconfig.json中的路径映射名称向optionalDependencies添加一个假包,并使用npm install --no-optional安装依赖项。 不幸的是,这不适用于yarn --ignore-optional - 它仍然无法尝试获取包。

所以, tsconfig.json路径看起来像这样:

    "paths": {
        "~/*": ["src/*"],
        "some-path/*": ["whatever/*"]
    }

package.json是可选的,如下所示:

    "optionalDependencies": {
        "~": "tslint-hack",
        "some-path": "tslint-hack"
    },

应该可以使用npm install --no-optional安装生产和开发依赖项。 这显然假设您不需要安装任何可选的依赖项。 另外值得一提的是,我没有使用@作为包名。

如果您选择使用此 hack,将.npmrc文件添加到项目根目录可能是明智的,并配置了optional=false ,这样您就可以继续运行npm install而无需--no-optional标志。

_应该_工作的另一个解决方案是实际创建一个具有所需名称的包并将其发布到私有注册表,使用verdaccio或类似方法。 我相信可以使用.npmrc.yarnrc为每个模块配置私有注册表,因此在可维护性方面应该更好。 但是,这些都没有经过测试。

希望这可以帮助那些想要使用这个 tslint 规则并保持他们的模块分辨率到位的人。 但这并不能代替适当的修复。

也有这个问题,导致声纳错误地将此标记为代码异味。

我认为这是一个有效的请求,因为 tslint 是关于打字稿的,而路径是一个有效(且重要)的打字稿设置。

如果我将package.json放在与tslint.json不同的目录中怎么办?

- web
    - package.json
    - ClientApp
        - tslint.json

我正在进行类似的设置,并且由于此规则,几乎所有文件中都出现错误。 有什么解决办法吗?

我找到的解决此问题的方法是使用以下配置选项。

"no-implicit-dependencies": [true, ["src", "app", "~"]]

它将提供的路径列入白名单。 显然,这意味着重复,但如果您正在寻找一个,这是一个快速解决方案。

对于我们这些使用@符号作为自定义路径前缀的人,我提出了一个 PR 来修复当前实现的一个小错误 #4192

"no-implicit-dependencies": [true, ["@src", "@app", "~"]]

@ifiokjr我使用@作为我的 src 别名,所以我的导入看起来像@/components
无法将@为忽略的路径,因为它试图将@/components作为整个模块导入,而不是首先解析@

我将别名更改为~并在我的 tslint 中使用了上面的行,解决了问题

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

calebegg picture calebegg  ·  42评论

sheam picture sheam  ·  31评论

adidahiya picture adidahiya  ·  30评论

adidahiya picture adidahiya  ·  52评论

mastrauckas picture mastrauckas  ·  46评论