Measured upm size on disk: 256 KB (Source: Socket, reporting Pooya Parsa's project size comparison (September 29, 2026))
Many teams may never have chosen how their software gets assembled. A tool makes the choice, and its default setting quietly becomes policy. A new package manager called upm is a small, useful case study in that idea.
A package manager downloads the third-party code a software project depends on. Socket's blog reported on upm on September 29. Its creator is Pooya Parsa, a longtime Nuxt contributor who also created Nitro and UnJS. upm works with the npm registry, the public library of JavaScript code.
Two defaults aimed at known attacks
upm ships with two security defaults. The first is that it does not run dependency lifecycle scripts during installation. These are small programs a package can trigger automatically the moment it lands.
The second is a 24-hour hold on new releases. If the latest version is too fresh, upm picks the newest older version that qualifies.
Socket presents both as answers to familiar npm attack paths. One is an install script that executes immediately. The other is a brand-new release that enters a project's dependencies before anyone has had time to inspect it.
Socket does not compare these defaults with other package managers, so check what your own tool does out of the box. The upm project's benchmark guide also turns lifecycle scripts off for every manager it tests. Those speed results therefore say nothing about each tool's own defaults.
The hold can be changed or switched off. That matters because of where the burden sits. A team has to decide to lower its guard, rather than remember to raise it.
How the rest of the design works
Each package in upm can reach only the dependencies it lists for itself. There is no hoisting, which means packages are not lifted into a shared spot where an unlisted neighbour could use them by accident.
To save space, upm's shared store uses hardlinks. These let several projects point at one physical copy of a file. Where hardlinks are not available, it makes plain copies.
The tool is also built to be embedded. Its commands are exposed as JavaScript functions, so another program can run the installer without starting a separate process. The store accepts pluggable backends, such as shared caches.
What the speed claims do and do not show
In the project's own cold-install tests, upm came out ahead overall on Nitro, Nuxt and Next.js projects. Its median times sat between 494 ms and 1.07 s. pnpm 12 beat it on Nitro.
The repeat-install test is less flattering. Here the cache and lockfile stay in place and only the node_modules folder is deleted. upm finished fourth, at 36 to 125 ms. Bun, aube and Deno were quicker.
Socket adds two cautions about the size chart. It estimates how long a cache takes to restore, not a full CI job. And the Bun and Deno figures bundle their runtimes, so the comparison is not like for like.
All the figures come from the project's own benchmarks. Outcomes differ by project, machine and network.
The limits are real
upm is a prerelease. It has no update command. It cannot install dependencies from Git or local folders. Peer dependency handling is limited. Proxy and certificate settings are unsupported.
Security auditing is also off the table for now. npm cannot read how upm lays out files or its lockfile, so audit-style commands do not work through it.
The defaults have edges too. Packages that compile code or fetch files as part of installation may need extra setup. The delay does not swap out a version already recorded in upm.lock. It does not override an exact version someone requests by name. If nothing old enough fits a requested range, the install fails.
An established project can try upm without converting anything first. If the project has no upm.lock, upm can fall back on a lockfile left by another tool: package-lock.json, pnpm-lock.yaml or bun.lock. It installs the versions that file lists and leaves the file as it was.
This route has major limits. It does not work if the existing lockfile involves workspaces, patches, or Git or file dependencies. In this mode, editing the dependency list is also off the table.
What this shows
One young tool says little about the wider market. Socket calls it early days and says it remains to be seen whether upm gains adoption.
The lesson here is narrower. A package manager's defaults are decisions about risk, made before anyone on your team looks at them. Do you know when your builds fetch new versions? Do you know what code runs while they land? If nobody can answer, that is worth fixing, whatever tool you use.
Questions to put to your engineering team
Ask whether dependency install scripts run automatically in your builds, and who approved that. Ask whether your tooling waits before adopting a newly published version. Ask which builds would break if scripts were skipped, and what the extra setup would cost.
Ask who owns exceptions, such as pinned versions that bypass a delay. Trial upm on a low-risk project if it interests you, given its prerelease gaps. The bigger return comes from learning what your current defaults decide for you.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Socket.
