gwin · galewind-npm
GaleWind installs, updates, and shares your Node.js packages — with workspaces that let a whole folder of projects skip redownloading what they already have between them.
MIT licensed · Node.js 18+ · gwin and gwix on your PATH
$ npm install -g galewind-npm
$ gwin i prompts
✓ resolved from local cache 0.2s
✓ 1 package installed
$ gwin ci
✓ lockfile pins matched, skipped registry
✓ installed from cache 0.4s
One global install gives you two commands: gwin,
the main tool, and gwix, for running a
workspace package's CLI without adding it to your PATH.
# install gwin globally
npm install -g galewind-npm
# check what you're on
gwin -v
# install everything in package.json
gwin i
Global installs land in ~/.galewind/global.
The first time you install, update, or promote something globally,
gwin adds it to your PATH automatically — on Windows it writes
setup steps to ~/.galewind/PATH_SETUP.txt instead.
Two things in particular do the heavy lifting: a short-lived memory of package listings, and a cache that lets a clean install skip the registry altogether.
01
Gwin holds onto a package's listing — name, versions, download
location — for a few minutes after it looks it up. The same
package showing up twice in your dependency tree, or a second
gwin i shortly after the
first, reuses that answer instead of asking again.
02
If your lockfile's pinned versions are already sitting in the
shared download cache, gwin skips the "what version is this?"
round trip entirely and installs straight off disk. It's the
reason a clean gwin ci
feels close to instant.
03
The shared cache tracks hits and last-used times in a
.pkg_cache file, so once
it passes a size cap (3GB by default) it evicts whatever's been
used least — not just whatever's oldest on disk.
Register a parent folder as a workspace once, and every project inside it can use the same installed packages — no per-project downloads. Need a package that isn't in this workspace but lives in another one you've registered? Gwin reuses that copy too.
Workspace commands in the docs →# register a folder once
gwin -w "~/Projects" name "my-projects"
# every project inside shares this
gwin -w my-projects i lodash
# stop typing -w on every command
gwin bind -w my-projects
gwin i lodash
why switch
GaleWind lands in the gap between the npm-compatible package managers and the workspace-first ones: it's noticeably faster than npm and Yarn Classic, it keeps disk usage down the way pnpm does, and it goes a step further with a background daemon that keeps its own startup cost close to zero.
01
A short-lived registry cache, cache-first installs when your lockfile is
already satisfied, and concurrent downloads/extraction (tunable with
GWIN_CONCURRENCY) all add up before the
daemon even gets involved.
02
gwin --daemon-enable keeps a warm gwin
process running in the background, so every command after the first skips
Node's startup and module-loading cost entirely. It shuts itself down after
30 minutes idle, and gwin falls back to running normally if it's ever
unreachable — nothing depends on it being up.
03
Workspaces let a whole folder of projects share one set of installed packages instead of each downloading its own copy — and a project can even reuse a package already sitting in a different workspace you've registered. Less disk, fewer redundant downloads.
04
gwin talks to the standard npm registry, respects package.json
and lockfiles, and skips install scripts by default for safety. No new
registry to trust, no new package format to learn.
how it stacks up
Roughly speaking, gwin sits between pnpm and Yarn: faster than Yarn Classic and npm on repeat installs, disk-conscious like pnpm, and quicker to even start responding thanks to its daemon.
| Tool | Install speed | Disk usage | Startup / daemon | Workspaces | Best for |
|---|---|---|---|---|---|
| npm | Slowest of the four — no shared cache across projects, resolves and re-verifies more on the registry. | Highest — every project gets its own full node_modules. |
No daemon; full Node startup on every command. | Basic (monorepo workspaces only, no cross-workspace linking). | Zero-setup compatibility; ships with Node itself. |
| Yarn | Classic (v1) is comparable to npm; Berry (v2+) is faster with Plug'n'Play but has a learning curve. | Moderate — a global cache helps, but Classic still duplicates into each project's node_modules. |
No background daemon; each command starts fresh. | Strong, mature monorepo workspaces. | Existing Yarn/PnP monorepos already invested in the ecosystem. |
| pnpm | Fast — a content-addressable store means most installs are just linking, not downloading. | Lowest of the mainstream tools — one physical copy of each package version on disk, hard-linked everywhere. | No daemon; startup cost paid on every invocation. | Excellent, purpose-built workspace protocol. | Disk-conscious teams running many packages/monorepos. |
| GaleWind (gwin) | Fastest here in practice — short-lived listing cache, cache-first installs, and an optional daemon that removes Node startup cost entirely. | Low — one shared, self-trimming download cache reused across every registered workspace, so a folder of projects stores packages once. | Optional background daemon (gwin --daemon-enable) keeps commands warm; auto-idles after 30 min and falls back safely if unreachable. |
Register any folder as a workspace after the fact, bind to it, and link packages across separate workspaces without republishing. | Teams juggling several small projects who want npm-compatible speed and low disk usage without a big migration. |
Speed and disk comparisons describe typical behavior of each tool's design, not a specific formal benchmark run.