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

  • Open
  • quality assurance status badge
Details
2 participants
  • Nicolas Graves
  • Javier Olaechea
Owner
unassigned
Submitted by
Javier Olaechea
Severity
normal
J
J
Javier Olaechea wrote on 2 Nov 06:34 +0100
(address . guix-patches@gnu.org)
CAFVS=zBVFDaVsmx6xA3Wf1F001j=uoUN0KGx7icANZEdg6A4AA@mail.gmail.com
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: file
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(+)

Toggle diff (37 lines)
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
N
N
Nicolas Graves wrote on 3 Nov 21:01 +0100
(address . 74173@debbugs.gnu.org)
87cyjcozmu.fsf@ngraves.fr
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
J
J
Javier Olaechea wrote on 4 Nov 05:59 +0100
(address . 74173@debbugs.gnu.org)
CAFVS=zAg0xWyynqsBEOUNunfc8=5DnfTs3uHvqOdqJFfDGZmbQ@mail.gmail.com
Toggle quote (2 lines)
> 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,
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: file
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 74173@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 74173
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch