feat: types with intellisense (#152)

[Dimava]

• Rewrite rules from Rule<ARuleOptions> to inlined Rule<[RuleLevel, 'option1' | 'option2']> to make understandable hover intellisence in defineConfig
• Rewrite rules from interface to type to shorten (property) ARule['a-rule']: Rule<[RuleLevel]> to (property) 'a-rule': Rule<[RuleLevel]>
• Remove unused calls and types
• Make sure all rules compile

[Dimava]

Variant 1:

Variant 2:

[Dimava]

(PR requires a rebuild and a cleanup, reqiring a review on if it looks properly at all)

[Dimava]

@Julien-R44 ref

[Dimava]

🤡 Variant 3 with Latin capital letter glottal stop: Ɂ

[Shinigami92]

Running pnpm run generate:rules results in some errors (tested on my Mac M1)

Additionally checking the diff after the generation

This does not look right to me

1. It should take AccessorPairsRuleConfig (RuleConfig), because the whole type/interface chain are build for that from top to bottom in each rule file.
2. I'm not sure if it is necessary to have never, never in each RuleConfigExt. If really needed, these should be defaults.

[Shinigami92]

The vitest type-check tests are failing, please have a look into them

[Dimava]

• cleanup leftovers
• manually fix leftover broken rules
• nr generate:rules && nr format && nr lint && nr typecheck ok
• regenerate test snapshot, nr test ok
  (nr is alias for pnpm run)

[Shinigami92]

I did not check every rule yet, but when I run pnpm run generate:rules the result is looking promising 🙂
So good work for now 👍

However, I'm tempted to split this PR into several commits to make it more discoverable in the commit history

I would like to split the "Apply handcrafted hard to generalize fixes" into its own PR and also add a terminal log to notify everytime a rule was "patched"

[Shinigami92]

This now needs to be rebased

[Dimava]

I thing I could really use a diff-generator script

I have like 10 rules to fix, doing that by hand is becoming hard

[Shinigami92]

In that case we should use the package rimraf

[Shinigami92]

@Dimava I have checked and tried to add such a preflight script, but deleting src/rules would also result in deleting other files that wont get regenerated
So all in all it might be a bad idea and we should just leave as is
The files will be automatically overridden when they get generated anyways
A human should always check the diff before pushing to git always (as I already did for everytime I generate rules)

[Shinigami92]

@Dimava I checked the PR freshly and run pnpm run generate:rules
Then I looked into .eslintrc.js and saw a bunch of errors
These need to be fixed!

e.g. RuleLevel should also be a singular config option if the other options are optional

Beside that, I'm not quite sure what you mean by

Rewrite rules from Rule to inlined Rule<[RuleLevel, 'option1' | 'option2']> to make understandable hover intellisence in defineConfig
Rewrite rules from interface to type to shorten (property) ARule['a-rule']: Rule<[RuleLevel]> to (property) 'a-rule': Rule<[RuleLevel]>

Right now the diff of the PR is really huge and I'm not sure if there is even a difference between type and interface in these cases.
Please provide me a screenshot what would be different by using type over interface

[Dimava]

@Dimava I have checked and tried to add such a preflight script, but deleting src/rules would also result in deleting other files that wont get regenerated

That's why I deleted srcr/rules/*/

[Shinigami92]

@Dimava please also answer my second question as well

Check the branch and run pnpm run generate:rules and you will see that far more than 100 rules are updated
So what is the benefit out of that?

---

Copy of my question above:

Beside that, I'm not quite sure what you mean by

Rewrite rules from Rule to inlined Rule<[RuleLevel, 'option1' | 'option2']> to make understandable hover intellisence in defineConfig
Rewrite rules from interface to type to shorten (property) ARule['a-rule']: Rule<[RuleLevel]> to (property) 'a-rule': Rule<[RuleLevel]>

Right now the diff of the PR is really huge and I'm not sure if there is even a difference between type and interface in these cases.
Please provide me a screenshot what would be different by using type over interface

[Shinigami92]

stale