Tslint: Failing at checking dependencies against package.json

[alexjoverm]

Bug Report

• __TSLint version__: 5.8.0
• __TypeScript version__: 2.5.3
• __Running TSLint via__: CLI

Description

If you take a look at this PR the build is failing just by updating the version of TSLint.

Actual behavior

Yells about missing dependencies in package.json when they actually are there.

Expected behavior

Just works.

[ajafff]

All dependencies in your package.json are devDependencies.

If the files in tools/ are intended to be published, you also need the packages used there as peerDependencies.
If they are only relevant for development and are not published, you need to add the "dev" option to the no-implicit-dependencies rule.

[adidahiya]

the build is failing just by updating the version of TSLint.

tslint:latest does not follow semver. See docs here.

I realize now that the default strictness of no-implicit-dependencies is not suitable for general use and should not be promoted to tslint:recommended. Rather than removing the rule from tslint:latest, though, I think we should change the default behavior of the rule to be less strict (allow imports of any package in dependencies, devDependencies, or optionalDependencies). Thoughts?

[dsole]

Making it less strict in that way is similar to just switching it off by default is it not ?

Generally I think its behaviour is correct - for production code the packages should be under "dependencies". For code related to development - such as unit tests - then they can allow packages under "devDependencies" and for these situations I'd expect a different ( probably less strict ) set of lint rules to be used anyway. In that less-strict ruleset, devDependencies would be enabled as appropriate.

[adidahiya]

Making it less strict in that way is similar to just switching it off by default is it not ?

No, you still have to declare imported packages as dependencies _somewhere_ in the package.json closest to the file being linted, and I believe it is still generally useful. This looser check still addresses the original intent of the rule, which was to mitigate issues caused by dependency hoisting in Lerna monorepos.

I personally would like to avoid having multiple tslint.json files for source vs. test code, as this would produce a lot of config files in my monorepos. So loosening the rule as I suggested would work well for me. Users who want to make their checks even stricter than tslint:latest can configure additional tslint.json files.

[JoshuaKGoldberg]

☠️ TSLint's time has come! ☠️

TSLint is no longer accepting most feature requests per #4534. See typescript-eslint.io for the new, shiny way to lint your TypeScript code with ESLint. ✨

It was a pleasure open sourcing with you all!