[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#51838] [PATCH v2 05/26] guix: node-build-system: Add #:absent-depen

From: Philip McGrath
Subject: [bug#51838] [PATCH v2 05/26] guix: node-build-system: Add #:absent-dependencies argument.
Date: Sat, 20 Nov 2021 12:04:49 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1


On 11/20/21 02:41, Liliana Marie Prikler wrote:

Am Freitag, den 19.11.2021, 23:33 -0500 schrieb Philip McGrath:
Many of Guix's Node.js packages are built without some of the
dependencies they specify in their "package-lock.json" files,
either because we don't have them packaged yet (e.g. test
utilities) or because we don't want them (e.g. to reduce the
closure size). Previously, Guix package definitions would work
around this situation by deleting the `'configure`
phase (i.e. the initial `npm install`).

This commit adds an optional #:absent-dependencies argument to
`node-build-system` to list Node.js packages that should be
removed from the "package.json" file.Retaining the `'configure`
phase avoids skipping checks for the dependencies that are
intended to be present and other actions performed by `npm
install`, such as automatically building native add-ons with
`node-gyp` when the "gypfile" key is present.

This is a somewhat decent approach, but I wonder whether we could
improve this.  Does nodejs complain if a dependency exists in the code,
but is not present in the packages.json?

To the best of my understanding, npm doesn't inspect the js files at all by default, so no. (A package.json file might define a build script that does more checks.) I think a missing and undeclared dependency manifests itself as a runtime error when the require() function is evaluated.

In the resolve-dependencies subprocedure, we could check whether we
have a matching input somewhere and only include the dependency if we
do.  WDYT?

I thought about this, but it seems to me there are two problems. First, I'm very unsure about this, but, in the last few days, I've gotten the impression there may be some "package.json" packages that don't correspond directly to Guix packages. I don't really understand how that works, but I think it may have something to do with npm packages that can run either on Node.js or on the web and need to use some functionality that's part of the Node.js core but not the web platform (or vice versa?). I could be wrong about that, but I've tried, especially in v2, to only have the build-side code do things I'm confident are correct in all cases.

The other issue is that deleting packages with no matching input by default would replicate some of the drawbacks of the current `(delete 'configure)` approach. I think it's better to have an explicit list of dependencies that Guix is deleting. If eventually we package all of the missing dependencies for Guix, it would be much easier to find the packages that ought to use it. And, in the highly dynamic JavaScript world, I'm reluctant to give up one of the few static checks we have. If a missing package that really was required were automatically deleted from "package.json", it seems the failure mode would by a mysterious runtime error, potentially many steps down a dependency chain.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]