Arch Linux User Repository

I'm going to do a best-effort to update this regularly considering the frequency of upstream updates. If someone can do better, let me know, but for now I'll just keep updating when I have a chance. Better than nothing, I think ;-)

The upstream release cadence is so nuts because they've automated things like javascript dependency updates. I don't think it necessary to hit every one of those since they aren't really updated code releases, if you know what I mean.

I'm trying to update this package, but I get the following:

The AUR is down due to maintenance. We will be back soon.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I guess I'll wait and try later. Not sure why I'm getting this message since the AUR doesn't actually seem to be down for maintenance.

@chico Like this? https://pastebin.com/dE7qF7ji

I still can't replicate the problem. I did a clean build on my system, but it creates fine.

I can reproduce @oli's failure on a normal Arch system.

Environment: nodejs-lts-krypton 24.14.1-3 npm 11.14.1 node-gyp 12.3.0-1 installed from [extra]

The build still fails in package():

sharp: Attempting to build from source via node-gyp
sharp: Found node-addon-api
sharp: Please add node-gyp to your dependencies

So the issue does not appear to be that the Arch node-gyp package is missing. The system package is installed. The problem is that sharp's install/build script expects node-gyp to be available in the npm dependency tree during the npm install.

A local workaround that builds successfully is:

npm install -g --prefix "${pkgdir}/usr" node-gyp node-addon-api ${_npmname}@${_npmver}

Then remove those build-only packages before packaging, otherwise pacman conflicts with the Arch node-gyp package:

rm -rf "${pkgdir}/usr/bin/node-gyp"
rm -rf "${pkgdir}/usr/lib/node_modules/node-gyp"
rm -rf "${pkgdir}/usr/lib/node_modules/node-addon-api"

Without the removal step, installing the built package fails because it tries to own /usr/bin/node-gyp and /usr/lib/node_modules/node-gyp, already owned by the node-gyp package.

This still feels like a workaround around npm install-script behavior, but it fixes the current package() failure.

@oli, when I use extra-x86_64-build to build this in a chroot, node-gyp gets install automatically without me specifically adding it in the depends. I think it gets pulled in with npm, so I don't think it needs to be listed separately.

It looks like node-gyp needs to be included in the dependencies.

npm error command sh -c node install/check.js || npm run build npm error > sharp@0.34.5 build npm error > node install/build.js npm error npm error sharp: Attempting to build from source via node-gyp npm error sharp: See https://sharp.pixelplumbing.com/install#building-from-source npm error sharp: Found node-addon-api npm error sharp: Please add node-gyp to your dependencies

I think npm should be a normal dependency, not a make dependency. For instance netlify dev needs npm to install things.

The latest release has some node warnings on the command line. I don't think this affects functionality, but I'm not sure if people want me to package this?

(node:1136716) ExperimentalWarning: The Fetch API is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
wasm streaming compile failed: TypeError: Failed to parse URL from /usr/lib/node_modules/netlify-cli/node_modules/netlify-redirector/lib/redirects.wasm
falling back to ArrayBuffer instantiation

I'm going to do a best-effort to update this regularly considering the frequency of upstream updates. If someone can do better, let me know, but for now I'll just keep updating when I have a chance. Better than nothing, I think ;-)

The upstream release cadence is so nuts because they've automated things like javascript dependency updates. I don't think it necessary to hit every one of those since they aren't really updated code releases, if you know what I mean.

Due to the crazy release cadence of this package (10 releases in the past week), I've been having trouble keeping up. If anyone is interested in being a co-maintainer (or taking over maintenance entirely), please let me know. Otherwise, I'll continue to release updates when I can.

I have considered completely automating the update process, but I think there is value in reviewing upstream releases before pushing them, especially given some of the recent prominent supply-chain attacks.

@mutantmonkey after some research I came to the conclusion that adding dependencies to a nodejs PKGBUILD is not a good idea.

Therefore forget everything I wrote, since it is just wrong.