Consider not wrapping types

[Dimava]

If instead of

export type PreferGlobalProcessOption = 'always' | 'never';
export type PreferGlobalProcessOptions = [PreferGlobalProcessOption?];
export type PreferGlobalProcessRuleConfig = RuleConfig<PreferGlobalProcessOptions>;
export interface PreferGlobalProcessRule {
  'n/prefer-global/process': PreferGlobalProcessRuleConfig;
}

the typings would use

export interface PreferGlobalProcessRule {
  'n/prefer-global/process': RuleConfig<[('always' | 'never')?]>;
}

the intellisence would hint the type as

(property) PreferGlobalProcessRule['n/prefer-global/process']: RuleConfig<[("always" | "never")?]>
(property) NoSyncRule['n/no-sync']: RuleConfig<{
    allowAtRootLevel?: boolean;
}>

which may be more understandable for simple types

The same thing also could be done on the type level of defineConfig itself

[Shinigami92]

I think a good starting point for you would be to look what you can do in https://github.com/Shinigami92/eslint-define-config/blob/main/scripts/generate-rule-files/src/rule-file.ts
But compile is coming from json-schema-to-typescript, so I have no idea how much luck you will have with that.

[Julien-R44]

I'm not sure it's very relevant. It might be if the rule only offers one option. But what about other rules that can accept up to 3 parameters? Let's take this one for example:

https://github.com/Shinigami92/eslint-define-config/blob/main/src/rules/vue/html-comment-content-newline.d.ts

I believe the resulting type would be much more complicated to understand than the one we have now.

---

However, yes, we can apply this system to rules that only offer one option. I'm not yet convinced of the relevance of adding this, but if you think it is, I think we can reconsider this PR #142

This would be a perfect use case. Just add a new module like "RewriteSimpleTypes", this new module would accept the AST as a parameter, and check if the rule contains just one option. And if it does, it would rewrite the AST to propose a simpler type. And the RulePatcher would then rewrite the file.

This is the whole principle of the RulePatcher :

So we have the RulePatcher class, which is just a kind of container on which we will register modules. These said modules will be applied at the end of the rule file generation. Each of these modules will have access to the AST of the generated file, and can modify it. Once all the modules have been applied, the source code is generated from this modified ast.

[so1ve]

Just add another wrapper type:

type Simplify<T extends object> = {
  [K in keyof T]: T[K]
} & {}