upm Launches as a Fast, Tiny Package Manager Written in TypeScript

A new package manager named upm has been introduced, written in TypeScript, and designed to be fast and small, occupying approximately 250 KB. It utilizes Node.js features, including networking, worker threads, compression, and filesystem tools. The tool provides a JavaScript API and reads supported .npmrc settings, allowing installation from other package manager lockfiles. Proponents argue that existing tools like npm are slow, pnpm is growing complex, Yarn has become convoluted, and alternatives like Bun or Deno are best used as runtimes rather than standalone package managers.
The performance benchmarks show upm ranks first overall for cold installs across Nitro, Nuxt, and Next.js with median times between 494 ms and 1.07 s, although pnpm 12 is faster on Nitro. Warm installs show mixed results, with upm ranking fourth at 36–125 ms when cache and lockfiles are preserved but `nodemodules` removed.
upm supports familiar configuration settings like scoped registries and credentials, and it can utilize lockfiles from other managers without modification. It enforces dependency isolation by preventing unintended hoisting of undeclared dependencies via hardlinks in its shared store. Security features include skipping dependency lifecycle scripts and enforcing a 24-hour release cooldown to mitigate risks associated with malicious installation scripts and recent releases.

* upm is a TypeScript package manager.
* It uses Node.js's built-in networking, worker threads, compression, and filesystem tools.
* It has a JavaScript API and reads supported .npmrc settings.
* It can install from various other package manager lockfiles.
* The measured upm build takes 256 KB on disk and 84.5 KB packed.
* pnpm 12 took 48.6 MB in the same test.
* upm ranks first overall on cold installs across Nitro, Nuxt, and Next.js with median times of 494 ms to 1.07 s.
* Warm installs show upm ranking fourth at 36–125 ms when cache and lockfile are kept but `nodemodules` is removed.
* upm skips dependency lifecycle scripts during installation.
* It defaults to a one-day minimum release age for new versions.
* upm supports install, add, remove, and run commands.
* The package store uses hardlinks for file reuse.

The narrative positions upm as a solution to the perceived bloat, complexity, and inherent risks found in established JavaScript tooling by leveraging existing, high-performance Node.js capabilities. The pattern of questioning existing standards—npm's slowness, pnpm's complexity, Yarn's conceptual overhead—suggests a systemic fatigue among developers regarding toolchain management where performance often conflicts with feature richness. The emphasis on making the tool "small enough to embed" and directly callable from JavaScript speaks to a desire for deeply integrated, low-friction tooling rather than external process management.
The tension between speed benchmarks (cold installs) and practical usability (warm installs, lockfile compatibility limits) reveals a common friction point: optimizing for raw performance often compromises integration and full compatibility. The security defaults, which skip potentially dangerous lifecycle scripts, represent an attempt to bake safety directly into the installation mechanism, which is a positive move that counters established attack vectors. However, the limitations noted—such as inability to handle specific lockfile structures (workspaces, Git dependencies) or peer dependency handling—suggest that the project is currently balancing external compatibility against internal architectural purity, setting up an ongoing negotiation for feature expansion within the community.
The implication for agency lies in whether a highly specialized, small-footprint tool can genuinely supersede established ecosystem tools when those tools are already deeply interwoven with existing workflows. The cost of this pursuit appears to be navigating specific technical trade-offs and managing feature creep; the immediate success is in establishing a benchmark for install speed within a constrained footprint, suggesting that velocity gains, even incremental ones, hold significant weight in tool development.
What assumptions about current developer workflows are being reinforced by prioritizing small size and direct embeddability over broad compatibility? How does the community balance the desire for bleeding-edge speed against the risk associated with locking down architectural decisions in a rapidly evolving dependency landscape? What is the long-term cost of adopting highly specialized, performant tools that intentionally limit feature sets?