typescript-tslint-plugin icon indicating copy to clipboard operation
typescript-tslint-plugin copied to clipboard

`rush-stack` integration (aka pick up `tslint` by walking `tslint.config` `extends`)

Open poelstra opened this issue 5 years ago • 1 comments

I'm setting up a monorepo based on Rush.

Specifically, I want each project in there to depend on e.g. rush-stack-compiler-3.3, which then depends on a specific version of TypeScript, TSLint, etc. This way, all these packages don't have to manually specify dependencies on e.g. the linter to use.

The current VSCode TSLint extension looks for my-project/node_modules/tslint, but in this case that version is located in e.g. my-project/node_modules/rush-stack-compiler-3.3/node_modules/tslint.

(Note: I'm using pnpm, as also recommended by Rush, to get a cleaner and more precise set of dependencies installed, which means I don't have the full 'flattened' list of packages that 'normal' NPM would install directly in my-project/node_modules.)

As @octogonz nicely described on Gitter:

RSC has an interesting solution for this problem that relies on the "extends" field supported by many JSON config files. The idea is to follow the "extends" field until we reach the last config file in the chain, and then we do NodeJS resolution in that folder to find the tool package.

The underlying reason for pushing tslint into a package like RSC is to reduce the copy+pasting between many projects that follow a similar stereotype, so it would make sense that there's probably also some config file boilerplate that we want to share (e.g. standard tslint rules or whatever).

Example: The rush/tslint.json file looks like this: { "extends": "@microsoft/rush-stack-compiler-3.2/includes/tslint.json" }

We follow this to rush/node_modules/@microsoft/rush-stack-compiler-3.2/includes/, and then when we call resolve() in that folder, it finds the version of tslint used by RSC-3.2. This algorithm is pretty general, so I think it would be reasonable for your VS Code plugin to implement it (perhaps as a fallback if there isn't a direct dependency on tslint).

It would be great if this plugin could use the same resolution algorithm (as a fallback) to locate a 'deeper' tslint.

poelstra avatar Apr 04 '19 08:04 poelstra

Hmmm, maybe I should have filed this in typescript-tslint-plugin repo instead. Just found that now, sorry.

poelstra avatar Apr 04 '19 08:04 poelstra

Closing as TSLint has been deprecated in favor of ESLint. We are archiving this repo as this project is no longer maintained

mjbvz avatar May 01 '23 20:05 mjbvz