[bug#74173] [PATCH] gnu: Add emacs-eslint-flymake.

[bug#74173] [PATCH] gnu: Add emacs-eslint-flymake.

[Javier Olaechea]

[-- Attachment #1.1: Type: text/plain, Size: 185 bytes --]

Hi,

Attached is a patch to add the eslint-flymake package. It is a flymake
backend for ESLint.

Cheers

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

[-- Attachment #1.2: Type: text/html, Size: 409 bytes --]

[-- Attachment #2: 0001-gnu-Add-emacs-eslint-flymake.patch --]
[-- Type: text/x-patch, Size: 1856 bytes --]

From 4217d5cf15193d90584dc63a9fe859df56ff8b5f Mon Sep 17 00:00:00 2001
Message-ID: <4217d5cf15193d90584dc63a9fe859df56ff8b5f.1730525463.git.pirata@gmail.com>
From: Javier Olaechea <pirata@gmail.com>
Date: Sat, 2 Nov 2024 00:26:22 -0500
Subject: [PATCH] gnu: Add emacs-eslint-flymake.

* gnu/packages/emacs-xyz.scm (emacs-eslint-flymake): New variable.

Change-Id: I0c5bb1279473d25ce16f7cf125620e819539bbfd
---
 gnu/packages/emacs-xyz.scm | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 488b4cb5d7..a994e4ab33 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -1484,6 +1484,28 @@ (define-public emacs-flymake
 called backends, and visually annotates the relevant portions in the buffer.")
     (license license:gpl3+)))
 
+(define-public emacs-eslint-flymake
+  (let ((commit "c78246330ee3ac1e0e07a709473d98a113d268e5")
+        (revision "1"))
+    (package
+      (name "emacs-eslint-flymake")
+      (version "0.2.0")
+      (source
+       (origin
+         (method git-fetch)
+         (uri (git-reference
+               (url "https://github.com/emacs-pe/eslint-flymake")
+               (commit commit)))
+         (sha256
+          (base32 "19h95k57hrsysmvqzillzfn6wcinvcidv14fvbaqxgigwfwj0jnw"))))
+      (build-system emacs-build-system)
+      (propagated-inputs (list emacs-flymake))
+      (home-page "https://github.com/emacs-pe/eslint-flymake")
+      (synopsis "An ESLint backend for Flymake")
+      (description
+       "This package lets flymake run ESLint on the current buffer.")
+      (license license:gpl3+))))
+
 ;; Package has no release.  Version is extracted from "Version:" keyword in
 ;; main file.
 (define-public emacs-project-mode-line-tag

base-commit: bb5ccbfc70e833dadb0e6445422c6254a9de3002
-- 
2.46.0

[bug#74173] [PATCH] gnu: Add emacs-eslint-flymake.

[Nicolas Graves via Guix-patches via]

Hi Javier,

I just took a quick look at the package and haven't tried to build it
yet.  Shouldn't it hardcode the eslint binary and add eslint as an
input?

I guess this would be necessary since we would probably expect that such
a package should work without requiring the user to explicitely install
eslint in its profile.

-- 
Best regards,
Nicolas Graves

[bug#74173] [PATCH] gnu: Add emacs-eslint-flymake.

[Javier Olaechea]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 1971 bytes --]