Install and pin
How a package arrives, what it installs alongside itself, and where the record of a release is kept.
Last updated 2026-09-21
Install any package by name:
npm add @sdxc/result
The version you get looks like a date, because it is one: a release is named for the day it was published. Write that date into your manifest exactly rather than as a range — Versioning covers the scheme and what an exact pin buys you.
What a package brings with it
When a package installs a sibling from this collection, that dependency is pinned exactly too, at the version it was built and tested with. This is also why a release day tends to publish more than the packages that changed: a dependent republishes so its pin can move.
The practical consequence is that mixing release dates can duplicate a shared dependency.
Installing @sdxc/spec@2026.9.4 beside @sdxc/jwt@2026.9.1 yields two copies of
@sdxc/duration when their pins differ; moving both to the same day collapses them.
Finding out what changed
There are no changelog files. The day's release is recorded as a git tag, v2026.9.4, and a
GitHub Release whose notes are the commits that went into it, with a compare link to the
previous release. That is the whole record, and it is the thing to read before a pin moves.