@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.
| Git Clone URL: | https://aur.archlinux.org/netlify.git (read-only, click to copy) |
|---|---|
| Package Base: | netlify |
| Description: | Create, deploy, and delete new sites hosted on Netlify straight from your terminal |
| Upstream URL: | https://www.netlify.com/docs/cli/ |
| Licenses: | MIT |
| Submitter: | BaloneyGeek |
| Maintainer: | macxcool |
| Last Packager: | macxcool |
| Votes: | 7 |
| Popularity: | 0.000001 |
| First Submitted: | 2018-01-03 13:25 (UTC) |
| Last Updated: | 2026-07-08 18:16 (UTC) |
@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.
@andreafeletto I'm not too familiar with how npm works, but currently these dependencies are getting bundled into this package under node_modules. Would installing these packages before building automatically change this behavior, or am I going to have to rework the build process?
Pinned Comments
macxcool commented on 2021-07-09 18:12 (UTC) (edited on 2021-07-09 18:16 (UTC) by macxcool)
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.