Tslint: New rule: no-implicit-package-dependencies

Created on 18 Sep 2017  路  4Comments  路  Source: palantir/tslint

I'd like a new rule to raise a lint error when I import a module that is not explicitly declared in the dependencies block of package.json. Like this eslint plugin: https://github.com/lennym/eslint-plugin-implicit-dependencies.

Motivation: this problem is an unresolved question when using dependency hoisting in monorepos: https://github.com/yarnpkg/rfcs/blob/master/implemented/0000-workspaces-install-phase-1.md#unresolved-questions

We should consider adding a linter configuration option to specify the location of package.json similar to --project (maybe --manifest). Alternatively, we could walk up the folder tree until we find a package.json for each linted file/folder (potentially expensive).

Rule Suggestion

Most helpful comment

The rule should have a "dev" option to also look at devDependencies.
That option could then be enabled for tests.

All 4 comments

:-1: for --manifest
Currently there is no way for rules to access anything but their config. We should not introduce some special behavior just for one rule.

Specifiying the path in tslint.json as rule option won't work, because we cannot resolve relative paths without knowing where the config comes from.

:+1: for using the findup approach. Although there might be a performance hit, we only have to do this once for every file that contains imports from node_modules.
Caching comes to mind, but that's not really possible as we don't know when to clear the cache. Ideally the host system caches these recurring file system operations and we don't need to worry.

Fair points, findup seems fine to me.

Do we need to handle path mappings specified in tsconfig.json?
https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping

The rule should have a "dev" option to also look at devDependencies.
That option could then be enabled for tests.

Was this page helpful?
0 / 5 - 0 ratings