dynamic/configurable shareable config based on the settings #16428
-
Hi 👋 I was wondering if there was a way to create a "dynamic" shareable config based on the settings. I'm trying to build an easy to setup and reusable opinionated shareable config. I want to put the emphasis on easy and reusable. I would like it, if the users of the config could be able to only set the "extends" and then choose the settings they want. Here's an example of what I would like it to look like to the end users: module.export = {
extends: ["the-multiple-purpose-shareable-config"],
settings: {
shareableConfigName: {
typescript: true,
jsx: "react", // "solid" | "preact" | "vue" | "...",
a11y: false,
prettier: true,
// ...
}
}
}; I don't know if it would be possible to do something like this: (if not could it be something that we consider adding to eslint?) // the-multiple-purpose-shareable-config.js
module.exports = (context) => {
config = {
// add all the basic thing
};
if(context.settings.typescript) {
// add plugins and thing related to typescript
}
if(context.settings.jsx) {
// things related to the JSX flavor
}
// ...
// we return the dynamicly created shareable config
return config;
} What do you think? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Hi @100terres! I don't think this could be based on As for other options, first, the current config system is frozen as we're working on the new config system, so any new features should be analyzed from the perspective of the new config system. In the new config system, there's no // eslint.config.js
import foo from "eslint-config-foo";
export default [
foo
]; I think your idea of dynamic shareable configurations could fit nicely into this, but instead of configuring settings separately users would just pass them directly to the config function: // eslint.config.js
import config from "the-multiple-purpose-shareable-config";
export default [
config({
typescript: true,
jsx: "react",
a11y: false,
prettier: true,
// ...
})
]; |
Beta Was this translation helpful? Give feedback.
Hi @100terres!
I don't think this could be based on
settings
becausesettings
are part of configurations, so it doesn't seem feasible for a configuration function to have access to the configuration it contributes to, which is not finalized yet at the point when the configuration function will be called.As for other options, first, the current config system is frozen as we're working on the new config system, so any new features should be analyzed from the perspective of the new config system.
In the new config system, there's no
extends
. Shareable configs should be loaded and included in the config array: