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.
Oh, that is a very good point. This has not been a problem with elm-review because Elm does not allow side-effects, but it’s different for JavaScript. Knowing JavaScript, it will likely become both a huge problem and a superpower…
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).
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).
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.
Oh, that is a very good point. This has not been a problem with elm-review because Elm does not allow side-effects, but it’s different for JavaScript. Knowing JavaScript, it will likely become both a huge problem and a superpower…
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 (likeeslint --print-configfor instance).