npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@liudonghua123/pkg-fetch

v3.6.1

Published

Compiles and stores base binaries for pkg

Downloads

71

Readme

pkg-fetch

[!IMPORTANT]
pkg-fetch has been deprecated with 3.5 as the last release. There are a number of successful forked versions of pkg-fetch already with various feature additions. Further, we’re excited about Node.js 21’s support for single executable applications. Thank you for the support and contributions over the years. The repository will remain open and archived.

This fork only adds node v20 support, used within @liudonghua123/pkg.

I have also started a similar project on https://github.com/liudonghua123/node-sea which use offcial single executable applications feature. Just try it as easy as npm i -g @liudonghua123/node-sea && node-sea -h.

A utility to fetch or build patched Node binaries used by pkg to generate executables. This repo hosts prebuilt binaries in Releases.

Binary Compatibility

| Node | Platform | Architectures | Minimum OS version | | ------------------------------------------------------------------------------------- | ----------- | ------------------------- | --------------------------------------------------------------------------------- | | 81, 101, 121, 14, 16, 18, 20 | alpine | x64, arm64 | 3.7.3, other distros with musl libc >= 1.1.18 | | 81, 101, 121, 14, 16, 18, 20 | linux | x64 | Enterprise Linux 7, Ubuntu 14.04, Debian jessie, other distros with glibc >= 2.17 | | 81, 101, 121, 14, 16, 18, 20 | linux | arm64 | Enterprise Linux 8, Ubuntu 18.04, Debian buster, other distros with glibc >= 2.27 | | 81, 101, 121, 14, 16, 18, 20 | linuxstatic | x64, arm64 | Any distro with Linux Kernel >= 2.6.32 (>= 3.10 strongly recommended) | | 16, 18, 20 | linuxstatic | armv72 | Any distro with Linux Kernel >= 2.6.32 (>= 3.10 strongly recommended) | | 81, 101, 121, 14, 16, 18, 20 | macos | x64 | 10.13 | | 14, 16, 18, 20 | macos | arm643 | 11.0 | | 81, 101, 121, 14, 16, 18, 20 | win | x64 | 8.1 | | 14, 16, 18, 20 | win | arm64 | 10 |

[1]: end-of-life, may be removed in the next major release.

[2]: best-effort basis, not semver-protected.

[3]: mandatory code signing is enforced by Apple.

Security

We do not expect this project to have vulnerabilities of its own. Nonetheless, as this project distributes prebuilt Node.js binaries,

Node.js security vulnerabilities affect binaries distributed by this project, as well.

Like most of you, this project does not have access to advance/private disclosures of Node.js security vulnerabilities. We can only closely monitor the public security advisories from the Node.js team. It takes time to build and release a new set of binaries, once a new Node.js version has been released.

It is possible for this project to fall victim to a supply chain attack.

This project deploys multiple defense measures to ensure that the safe binaries are delivered to users:

  • Binaries are compiled by Github Actions
    • Workflows and build logs are transparent and auditable.
    • Artifacts are the source of truth. Even repository/organization administrators can't tamper them.
  • Hashes of binaries are hardcoded in source
    • Origins of the binaries are documented.
    • Changes to the binaries are logged by VCS (Git) and are publicly visible.
    • pkg-fetch rejects the binary if it does not match the hardcoded hash.
  • GPG-signed hashes are available in Releases
    • Easy to spot a compromise.
  • pkg-fetch package on npm is strictly permission-controlled
    • Only authorized Vercel employees can push new revisions to npm.

Contributing Updates to Patches

Example workflow for applying patches to a new version of Node.js (18.13.0)

  1. Clone Node.js as a sibling to your current pkg-fetch clone
  • git clone https://github.com/nodejs/node.git
  • cd node
  1. Checkout the tag you wish to generate a patch for
  • git checkout v18.13.0
  1. Attempt to apply the closest patch (e.g. applying the existing patch for 18.12.1 when trying to generate a new patch for 18.13.0)
  • git apply ..\pkg-fetch\patches\node.v18.12.1.cpp.patch --reject
  1. If no rejects, great! you are ready to make your new patch file.
  • git add -A
  • git diff --staged --src-prefix=node/ --dst-prefix=node/ > ..\pkg-fetch\patches\node.v18.13.0.cpp.patch
  1. If rejects exist, resolve them yourself, and ensure all changes are saved, and repeat step 4 to export the patch file

Resolving Rejects

Usually when a patch is rejected, it's because the context around the changes was refactored slightly since the last patched version. This is not usually complicated to resolve, but requires a human to interpret the changes since the last version pkg was patched against, compared with the version you wish to create a patch for.

One method is to pull up the diff for the file where the rejects apply for the changes between the last tag (e.g. v18.12.1 to use the previous example) and the tag you want a patch for (e.g. v18.13.0 to use the previous example). Alongside this, have the .rej file and go through each rejected hunk by hunk and use your best judgement to determine how it should apply against the new tag.

Save you results, and export the overall git diff with the commands from the example above.

Checking that patches apply cleanly

The expectation is that a patch applies cleanly, with no delta or offsets from the source repo.

When making a change to a patch file, it is possible to apply that patch without building by running

yarn applyPatches --node-range node18

where the --node-range can be specified to apply patches for the version of node for which you are updating patches. If unspecified, the latest node version in patches.json will be used.

Ultimately, the patch should result in fully functional node binary, but the applyPatches script can be used to quickly iterate just the application of the patches you are updating without needing to wait for the full build to complete.

Building a Binary Locally

You can use the yarn start script to build the binary locally, which is helpful when updating patches to ensure functionality before pushing patch updates for review.

For example:

yarn start --node-range node18 --arch x64 --output dist