Hi Estelle, It really depends on your use case. For instance, if a company wants to provide configs for their projects, they very well may package custom rules with configs that configure both the custom rules and some ESLint core rules to keep everything together.
If, on the other hand, you are writing custom rules for the general public, you'd want the bundled configs to only configure your custom rules so as not to surprise or confuse your consumers. So it really just comes down to your use case. -N On Thu, Jul 14, 2016, 2:49 PM Estelle DeBlois <[email protected]> wrote: > Plugins define new ESLint rules, but they can also ship with a > configuration (e.g. recommended config for those custom rules). > > Is it considered bad practice to have that config also list out rules > outside of the ones that the plugin defines? In other words, could a > `eslint-plugin-foo` include a config that has settings for the plugin > rules, plus the following: > > 1) configuration for ESLint default rules > 2) configuration for other custom rules (this would require that the > plugin pull in other plugins as dependencies) > > I would think a separate `eslint-config-foo` repo that pulls in and > configures the rules from `eslint-plugin-foo`, possibly from other plugins, > as well as default rules would be preferable, but I've seen it done both > ways. > > Any best practice here? > > -- > You received this message because you are subscribed to the Google Groups > "ESLint" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ESLint" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
