Skip to content

Conversation

@JoshuaKGoldberg
Copy link
Contributor

@JoshuaKGoldberg JoshuaKGoldberg marked this pull request as ready for review April 23, 2025 19:21
@fasttime fasttime added the Initial Commenting This RFC is in the initial feedback stage label Apr 24, 2025
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?

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.

Copy link
Member

@nzakas nzakas left a 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, and meta.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?

@JoshuaKGoldberg
Copy link
Contributor Author

JoshuaKGoldberg commented Jun 16, 2025

I'm less convinced with some of the more ambitious parts of this proposal such as:

Added:

`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.

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?

Copy link
Contributor Author

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

cc4e515

Is that more clear? I'm having a hard time describing this.

Copy link
Member

@fasttime fasttime left a 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.

@JoshuaKGoldberg
Copy link
Contributor Author

@fasttime @nzakas I removed the config rules generation points and noted them as out of scope, similar to lazy-loading rules. The only modification the definePlugin function now would do is merging in a plugins array with the plugin set by meta.name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature Initial Commenting This RFC is in the initial feedback stage

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants