generally, I’m not a big fan of using Turing complete languages for configuration because the law of entropy dictates that eventually your configuration will depend on side-effects when it has the ability to.
So if the configuration should indeed be changed, IMHO, it should be changed to something entirely declarative that cannot depend on arbitrary side-effects.
I think ESLint rules already feel like they can’t do side-effects, but some do like the rules in eslint-plugin-import (to resolve imports or something, can’t remember more details).
You could probably use SES to sandbox the config, so it can’t actually perform external side-effects (though unlike elm could use mutation internally for its own computation – but that sees fine).
So, this is a really interesting idea. The one big downside that I see is that now anything that works with ESLint configs basically has to be written in JS (or Elm).
That is true, the questions I guess are what would external tools want to do with or extract from the ESLint config anyway.
For instance, https://github.com/sarbbottam/eslint-find-rules already tries to import (require()) the configuration file, so this tool already seems to work with JS files.
For other interesting use-cases, I think it would be better if ESLint’s CLI would add commands to give necessary information (like eslint --print-config for instance).