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).