New PortGroup: bun

[Oleksiy Akimov]

Hi all,

I have a PR open adding a new bun PortGroup: https://github.com/macports/macports-ports/pull/34030
As suggested by herbygillot, posting this here. Below is what the new PortGroup does.

WHAT IT IS FOR
Some packages published to npm cannot be run by node. They declare "engines": {"bun": ...}, ship a #!/usr/bin/env bun shebang, or import bun: builtins. npm-1.0 wraps installed bins with node, so those packages install and then fail at runtime. There surely will be more such packages.

The new bun PortGroup is modelled closely on npm-1.0: fetch the package's tarball from registry.npmjs.org, skip extraction, and hand the tarball to the package manager at destroot.

HOW IT INSTALLS
destroot runs:
    BUN_INSTALL_GLOBAL_DIR=${destroot}${prefix}/lib/bun/${name}
    BUN_INSTALL_BIN=${destroot}${prefix}/bin
    BUN_INSTALL_CACHE_DIR=${workpath}/.bun-cache
    bun install -g --verbose <distfile>

so, each port owns ${prefix}/lib/bun/${name} and nothing else. An earlier revision used a single shared global dir, which meant every port destrooted its own copy of the same package.json and bun.lock, and the second one to activate would have conflicted. bun writes relative symlinks for bins, so no destroot paths leak into the image; I verified that on the destroot images rather than taking it on trust.

Options: bun.rootname, bun.version (a floor on the runtime, checked at fetch and again before destroot), bun.trusted_dependencies, bun.add_dependencies. distname is derived from bun.rootname, so scoped packages do not need to set it by hand the way npm-1.0 ports do.

Some caveats to bear in mind:

NETWORK ACCESS AT DESTROOT
bun resolves and downloads the whole dependency tree from registry.npmjs.org during destroot. Only the top-level tarball is checksummed. There is no lockfile when installing from a bare tarball, so dependency versions can drift between builds; the build is not reproducible, it fails without network, and dependency licenses are not audited.
This is exactly what npm-1.0 already does, and this PortGroup does not make it worse. It might be a good idea to include an extended auditing function in the future.

LIFECYCLE SCRIPTS AND trustedDependencies
Unlike npm, bun does not run postinstall/prepare scripts unless a package is trusted- Absent a trustedDependencies field it falls back to a built-in allowlist of a few hundred packages.
The PortGroup always writes a trustedDependencies field, which replaces that default list rather than extending it. The effect is that script execution is declared by the port: only the packaged module itself and whatever the port names in bun.trusted_dependencies can run scripts. The alternative is an implicit allowlist that changes whenever devel/bun is updated, which seemed like the wrong default for a package manager running as part of a port build.
The cost is that a package bun would normally trust has to be named explicitly, sharp being the obvious one. destroot runs bun with --verbose, so anything blocked is named in the log.
Related limitation, documented in the PortGroup header: bun links a package's bins while installing and does not link them again after lifecycle scripts run, so a bin created by a postinstall never reaches ${prefix}/bin. Trusting the package does not help. destroot fails on the empty bin directory rather than installing a port with no binaries.

DOES IT EARN ITS KEEP WITH ONE CONSUMER
There are two now, and I intend to add more:
    https://github.com/macports/macports-ports/pull/34031 oh-my-pi
    https://github.com/macports/macports-ports/pull/34038 eslint

FOUNDATION
devel/bun is currently an npm-1.0 port: a small stub whose optional dependencies pull a prebuilt bun binary. So, bun PortGroup ports rest transitively on a binary download performed by node and npm. Its maintainer has said he no longer uses bun and would hand over maintainership, I am happy to support, but not fully take over.I have filed another PR building bun from source, https://github.com/macports/macports-ports/pull/34039 to make bun compile properly.

I am happy to write a Guide entry for the PortGroup reference chapter once the shape is settled. Comments or objections on any of the above welcome.

Disclosure: partially written with Grok 4.6.

Thanks,
Oleksiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20260814/4a36fd7a/attachment-0001.htm>