unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Nicolas Graves via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>
To: guix-devel@gnu.org
Subject: NPM packaging questions
Date: Mon, 19 Feb 2024 01:09:34 +0100	[thread overview]
Message-ID: <875xyll3gh.fsf@ngraves.fr> (raw)


Hi!

I'm currently delving in the subject of node packaging, I have a few
ideas that I might be interested in sending patches for, but I need some
input before.

1) IIRC, most build-systems (except cargo at least) will not fail if
some native-inputs are not present. They will fail if they are indeed
necessary to build the package, but not by construction. This is not the
case currently in the node-build-system. This forces us to use the
delete-dependencies function very extensively, but there are a lot of
cases (linters in a broad sense) where this is not necessary.

Should we do like in other build-systems and add a step that would use
this delete-dependencies function for all packages that are simply not
node packages in inputs / native-inputs / propagated-inputs?

Or sould we rather keep this explicit declaration with a need to
probably also include it and a list of linters to ignore when generating
a package with a potential importer?

2) Node tests will fail if there are no "test" script present. Based on
the code in node-acorn, we can define a utility function that can at
least check and filter-out a script in package.json. Based on this, we
could avoid the need to manually enter #:tests? #f when tests are not
present.

3) Likewise, the "prepare" step in an input is run in the configure
phase from packages that use this input. This is probably never correct,
since the input's output is fixed in the store. Using the same utility
as in (2), we could add a step that would
  a) warn the user that a prepare step is being removed and output the
  content of this step.
  b) filter-out this step.

These, and in particular (1) should make it more easy to tackle writing
node packages until we can come up with a correct importer that could
handle recursive import. I don't think introducing the binary importer
in guix is a good idea since typescript and gulp have been successfully
imported in guixrus.

-- 
Best regards,
Nicolas Graves


                 reply	other threads:[~2024-02-19  0:10 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875xyll3gh.fsf@ngraves.fr \
    --to=guix-devel@gnu.org \
    --cc=ngraves@ngraves.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).