Opal v0.2.1

A performance fix for one finding: a 367-package Next.js install spent most of its time parsing package metadata it never used, and almost none of it on the network.

To install Opal v0.2.1

Every package on the registry publishes a record of every version it has ever released. Opal was building the full dependency detail for all of them before selecting one. On that project it parsed 130,246 published versions to choose 367, then held the rest in memory and freed it again.

Version bodies are now kept as raw slices and parsed on demand.

Measured

On a 367-package Next.js tree with a warm store and warm metadata:

Also in this release

• Per-phase timings. 365 packages resolved in 587.1s described the whole install, not resolution. It now reads (resolve 43.2s, fetch 0.5s, link 13.5s), because those three phases are slow for unrelated reasons and one total hides which to fix.
• Fewer syscalls when linking. A 21,000 file tree made 21,000 create_dir_all calls where a few hundred would do. Invisible on ext4, and not on a DrvFS mount under WSL2.
• The hardlink warning now names the remedy. If your project and cache sit on different filesystems, every file is copied instead of linked, which can be most of an install's time. Set OPAL_CACHE_DIR to the same filesystem, or move the project off /mnt/c if you are on WSL2.

Note

A version a registry lists but cannot be installed from — no tarball, or no usable integrity — is now skipped in favour of the next best match, rather than being filtered out when the packument was first read.

No lockfile format change. v0.2.0 lockfiles are read as-is.

Full Changelog: https://github.com/saintparish4/opal/compare/v0.2.0...v0.2.1