Subject: [PATCH] gnu: Add emacs-eslint-flymake.

From: Javier Olaechea <[email-masked]>
Date: Mon, 4 Nov 2024 04:59:41 +0000

> Shouldn't it hardcode the eslint binary and add eslint as an input?

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

-- 
"I object to doing things that computers can do." — Olin Shivers