1. 7
  1. 6

    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.

    1. 4

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

      1. 1

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

    2. 2

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

      1. 2

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