I can see the argument for both cases. In favor of listing as a dependency is that the minor mode can be enabled globally out of the box and it will run successfully. I also checked other flymake packages included by GUIX, https://packages.guix.gnu.org/search/?query=flymake, like proselint and percritic and we _do_ include programs they depend on as a dependency. So including eslint as dependency seems aligned with our practices.  If we end up deciding to do this, should we include rubocop as a dependency of emacs-flymake? The flymake package ships with a rubocop backend.

The argument against is that ESlint is a program one runs in the context of developing software for a specific project. ESlint has multiple versions with different defaults. And one always wants to run the same version of ESLint that is specified by the package.json. As that is the version that will be used by CI. Personally I use npx to ensure that the version of ESLint being used is the project specific one w/o having to resort to project specific configuration.

My personal preference would be to not include it, but I'm fine either way. Let me know what you think.

A more practical consideration for not including ESLint as an input right now is that we don't have a package for it! I can look into packaging ESLint but I'd rather we block this patch until we package ESLint. It seems RDE has a package for it.

Cheers