Question: Is there any way we could work together to achive typed rule support in eslint-define-config?

[Shinigami92]

Hi 🙂 I'm the author of https://github.com/Shinigami92/eslint-define-config

I see that in this repo already some types exist: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/typings/eslint-rules.d.ts

Do you think it's possible in any way to reuse these in https://github.com/Shinigami92/eslint-define-config/tree/main/src/rules/typescript-eslint?

---

Another question: Is it possible that anyone can help me in eslint-define-config for support @typescript-eslint?
Contributions in any way are really welcome 😃

[bradzacher]

Hey that's awesome!
That looks not too dissimilar to an idea I was playing with a while back #1296.
Glad that someone is working in the space!

There are definitely too many rules to manually write types for. If you combine eslint and typescript-eslint you'll have hundreds of definitions to maintain - which isn't sustainable as you add more plugins.

In the past in personal projects I've done this generation automatically via a simple script - https://github.com/bradzacher/eslint-config-brad/blob/master/scripts/generateTypes.ts which generates types for the plugins - https://github.com/bradzacher/eslint-config-brad/tree/master/src/types

In a nutshell - this script reads the JSONSchema defined for each rule in a plugin and then uses json-schema-to-typescript to generate the types.
It's not 100% perfect because some rules declare slightly invalid configs - but it's good enough! For the rules that are wrong you can PR the plugin to fix the schema (I have done a few PRs to do this myself).

[Shinigami92]

A "problem" I have with auto-generating them is that they would not have e.g. JSDoc

Another thing is that the once that I already created are really strongly typed
So if someone tries to set beforeStatementContinuationChars for semi but uses always an compile time error is thrown

https://github.com/Shinigami92/eslint-define-config/blob/main/src/rules/eslint/semi.d.ts

---

But yes, maybe we could try generating it to have a huge starting point
And then I hoped that the community can just help to keep them updated if something is new or so

---

Do you want an invite to the repo? I will send you an invite 🙂

[Shinigami92]

Oh @bradzacher and if you want (don't know if I'm allowed to advertise my repo so much ^^) you can advertise it in the mentioned PR #1296

The current version of my package is already usable! right now!
So if anyone in the other PR wants to use it right now they should, and if they want to help they are welcome 👐

[fedeci]

Hi @Shinigami92, can't JSdocs be generated too? Babel automatically generates code for @babel/types, you can get some hints from that! I can give you a hand if you need it.

[Shinigami92]

@fedeci Yeah please! I never auto-generated types. Feel free to open any kind of PR or issue in the repo. So we can track anything further from there 👍

[bradzacher]

Another thing is that the once that I already created are really strongly typed
So if someone tries to set beforeStatementContinuationChars for semi but uses always an compile time error is thrown

You get the exact same guarantee from auto-generated types!

Here are the auto-generated types for the semi rule, which you can see does not allow beforeStatementContinuationChars if the option is always:
https://github.com/bradzacher/eslint-config-brad/blob/master/src/types/eslint/semi.ts

These types are generated from the JSON schema for the rule - meaning they will match the same runtime checks that are done by ESLint.

[Shinigami92]

Mh... but numbers are also allowed for severity 🤔
And it doesn't have JSDoc 🙁

I think if I just provide the most common used rules that are mostly not included in "recommended" extensions, I will serve a much more better quality and also code readability then if I just auto-generate everything

If I just add some rules every day... I mean they are only around 200 eslint rules and around 100 of the are in the "recommended". So in a month or so I could cover most needed eslint rules 😅 It's not impossible

[fedeci]

Wouldn't it become tough to maintain? 🤔

[Shinigami92]

I don't think so, cause I provide relaxed types
Like a predefined interface + extends Partial<Record<string, ...>>
e.g. https://github.com/Shinigami92/eslint-define-config/blob/2ccd3afeba34b89b06c30755b2c7043695236d9d/src/parser-options.d.ts#L18

And all rules that are currently not defined yet fallback to https://github.com/Shinigami92/eslint-define-config/blob/2ccd3afeba34b89b06c30755b2c7043695236d9d/src/rules/rule-config.d.ts#L6

And if a defined rule break it's typing cause of an update, the community can just open an issue/pr for that
And/Or just disable the type-safety for the line or so

[Shinigami92]

@fedeci I mean... I literaly jump into repos like vbenjs/vue-vben-admin#431 and provide types/fixes for them
just by observing https://github.com/Shinigami92/eslint-define-config/network/dependents 😅

[bradzacher]

Mh... but numbers are also allowed for severity

That's just part of the script.
https://github.com/bradzacher/eslint-config-brad/blob/075d2ba383ec5923c2b050a275f298334bea4bc1/scripts/convertRuleOptionsToTypescriptTypes.ts#L34-L36

I just do it with strings because I prefer the strings over the numbers.

If I just add some rules every day... I mean they are only around 200 eslint rules and around 100 of the are in the "recommended".
So in a month or so I could cover most needed eslint rules

But what about other plugins? There are hundreds of additional rules that you'd want to cover.
There are many rules that aren't in recommended sets (as they're opinionated), but they're used ubiquitously, like indent.

And it doesn't have JSDoc 🙁

You can always just add a JSDoc comment that links to the rule's meta.docs.url?
https://github.com/eslint/eslint/blob/master/lib/rules/semi.js#L26

Or you could augment my simple script to allow additional comments to be emitted if one has been added for a rule?

if (configuration[plugin][rule]) {
  comment = `/**\n *${configuration[plugin][rule].split('\n').join('\n *')}\n*/`
}

That would give you a "best of both worlds" scenario

---

I'm just thinking from the perspective of an OSS maintainer.
You don't want to burden yourself with having to maintain all of those comments and types by hand.
The ESLint contributor community is pretty small - so there won't be many people willing to pitch in.

I think it's an admirable goal, and in an ideal world it'd be the best state. But in reality you'll just spend a sink lot of time into it, and then have to keep an eye on every release to look for changes in all the plugins and repos

[Shinigami92]

Thanks I will definitely have a look into that
Currently I covered all my self used rules 👀
I could try to create a generator that auto-generates my wanted files, but I have the power of improving them by hand if needed

I expect generating something like this could be really hard

[bradzacher]

Generating it "cleanly" with template string types - yes, that would be nigh impossible to do as it would require understanding of the rule itself.

But generating the options by itself - nope that's trivial still:
https://github.com/bradzacher/eslint-config-brad/blob/master/src/types/%40typescript-eslint/member-ordering.ts

[Shinigami92]

https://www.npmjs.com/package/eslint-define-config already has around 17k dl/week 🚀 increasing 📈
I think I can close this issue for now
The only thing that could be done in the future would be to move my repo under eslint org to make it more official 💚