-
-
Notifications
You must be signed in to change notification settings - Fork 82
feat: definePlugin #132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: definePlugin #132
Conversation
designs/2025-define-plugin/README.md
Outdated
| This RFC's scope intentionally does include a "rule creator" factory akin to [`@typescript-eslint/rule-creator`](https://typescript-eslint.io/developers/custom-rules/#rulecreator). | ||
| Creating such a factory in ESLint could be useful but does not seem to be required for any of the problems `definePlugin` aims to solve. | ||
| Should a "rule creator" factory be tackled separately? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like an adjacent but separate conversation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the work and research you put into this.
At a high-level, I can see the value of a definePlugin() helper function that:
- provides type safety
- makes it easier to define configs
- enforces best practices (requiring
meta.name,meta.version, andmeta.namspace
I'm less convinced with some of the more ambitious parts of this proposal such as:
- lazy-loading rules
- autocreation of configs
By way of example, defineConfig()s goals were primary to provide type safety and add an extends key, so I'm wondering if maybe it makes sense to scale down definePlugin()'s MVP?
Co-authored-by: Nicholas C. Zakas <[email protected]>
Co-authored-by: Kirk Waiblinger <[email protected]>
Added:
|
designs/2025-define-plugin/README.md
Outdated
| `configs` is the only property `definePlugin` receives with a different shape than the output plugin object. | ||
| - If `configs` is not provided, a default config is generated. | ||
| - `configs` may be provided as a shape that does not include the plugin's name. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not totally following this... Are we saying that if I provide
definePlugin({
meta,
rules,
configs: {
[`${pluginName}/recommended`]: { /* ... */ },
config1: { /* ... */ },
config2: { /* ... */ },
}
});that all these configs should be transformed? Or that only the `${pluginName}/recommended` one will be? Or maybe something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you're right, this is weirdly phrased and kind of wrong. It's the first one. Each individual config will be transformed. Edited:
- This part just says it's an object whose properties describe the configs to create.
- Generated Configs describes the key-value mapping in more detail
Is that more clear? I'm having a hard time describing this.
Co-authored-by: Kirk Waiblinger <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work, and apologies for the delayed review. I've added some comments throughout. Given the length of the text, I may have missed something. Feel free to let me know if anything in my remarks seems off.
Co-authored-by: Nicholas C. Zakas <[email protected]>
Co-authored-by: Nicholas C. Zakas <[email protected]>
Co-authored-by: Francesco Trotta <[email protected]>
Summary
Adds a
definePluginfunction to@eslint/plugin-kitas a recommended way to group plugin configs, meta, and rules.Related Issues
definePluginfunction in@eslint/plugin-kitrewrite#176