Open KingDarBoja opened 4 years ago
Yeah this is a good question... The messaging here is a little better post-#299 but still not perfect. I wonder what the best way to tackle this would be. Would it be doable to statically detect through the TSLint project extensions that the rules are coming from a community plugin? If so, yay! - accepting PRs. If not, let's think a little bit more.
I think it is possible to do something like detecting the author of the package, if the name is not included on some array which stores official TSLint repo owners, then it will be a community plugin.
To retrieve the author data, we can use pacote as npm relies on it to fetch package metadata,
EDIT I checked this comment on SonarTS repo and looks like they already provide some way of migration to their own ESLint rules.
Maybe provide a custom message per community plugin could be useful too 🤔
@KingDarBoja you assigned yourself back in 2020; do you still have time to look at this? I can if not!
Sure, go ahead, I got pretty busy and lacking free time to look at these at the time being 😢
🚀 Feature Request
Following #151 example, if you try to convert TSLint rules into ESLint ones for some projects that make use of external static code analyzer like as Elm language client VSCode, you will see a long
tslint-to-eslint-config.log
file whose content is the following:As you can check at the source code, the tslint.json extends from
tslint-sonarts
, which is another static code analyzer for Typescript. The rule list can be found at readme at SonarTS repo.Existing Behavior
The above log file is being generated with tons of rules that are not supported by ESLint.
Change Proposal
Provide a notice which states external code analyzer are not supported by ESLint.
I am not sure if this should be of concern but I had to bring int into discussion.
Cheers!