@bartlangelaan what do you think about making tool instead of wrapper?

we could do 2 things there:

• migrate supported rules from tslint to eslint and generate config
• check configuration for not supported rules and copy configuration with overrides
  • it will be nice if there will be way to statically generate desired file
  • and we can leave option to use it as wrapper

i don't like that this is going to be in plugin, maybe we should make separated package for this?

I think a wrapper is the best option for most people, because if this project gets updated then the wrapper can automatically enable new rules if necessary. Users don't have to think about re-running the tool every time a new replacement rule is added to the plugin. Just updating the plugin would be enough.

I understand that it's a new thing and a new packagecould be good for that, but I think it's more user-friendly if the wrapper comes out of the box with the plugin. That's also because the wrapper is dependent on the right rules being available; it's easy to make the mistake of updating the wrapper without updating the rules, or the other way around.

I do think adding a tool that checks these things would be helpful for some, especially for power-users that want to configure every little thing themselves. It's a bit comparable to whateslint-config-prettier has: a little CLI tool that checks for rules that conflict with Prettier. If something like that would be added to this repo that would be awesome; but for 'normal' users I think it would be more friendly to also provide a wrapper. So that's what I would like to focus on in this proposal.

Note that there'seslint/rfcs#9 which might help deal with this.

I don't think such a tool belongs directly in the plugin's package, though it could live in this monorepo.
We've gotten a lot of user feedback about mixed codebases, so it might be a worthwhile endeavour to improve ease of adoption.

• Disables rules that are incompatible with or unnecessary for TypeScript

This is an unbounded set. There are a huge number of plugins which provide rules that might already be caught by typescript. I would recommend not providing a blacklist, or else we could possibly playing catchup with users reporting rules that are double reporting with TS's compiler.

Would mean we'd have to switch the list that gets disabled based on the plugins installed by the user. Note eslint will throw if you include rules that don't exist; so (depending on the list of rules from plugins) there's the chance that we'd have to detect plugin versions.

A bit of bike shedding, but something to think about.

Note that there is a lot of parts of this repo that will work on both JS and TS files.
The parser should work on both.
All of the override rules should work on both.
Rules inspecting TS specific constructs (interfaces, types) should work on both (because those nodes never show up).

Essentially there's one set of rules which will not work on JS files:
Rules requiring TS specific features (such asexplicit-function-return-type) will not work on both.

It'd be nice if the new package were written in a way that made it seamless to reuse its logic in a standalone CI helper, for teams that use JSON config formats...

for teams that use JSON config formats...

From what I've been told - in future versions of ESLint JSON config files will be deprecated. I believe that they want to standardise on JS config files as they are easier to work with in general, and it simplifies ESLint's config resolution and parsing logic.

Moving this to a discussion because we should hammer out what this configuration helper should look like. What is the API? How are you expected to call it?

The new flat config will likely require us to create a helper package to bundle up the entire project and it's configs in a standardised way.

So such a package wpuld us a good place to export such a config utility. Even if the utility starts as an identity function purely for types.

This helper roughly exists in v7. Seehttps://typescript-eslint.io/blog/announcing-typescript-eslint-v7. Cheers all! 💙