denoland/std: the Deno standard library, one JSR package at a time

Fifty directories that became fifty packages

The repository tree reads like a single library's source layout, which is exactly what it used to be. Each top-level directory is now a separately published JSR package under the `@std` scope.

assert/
async/
bytes/
crypto/
csv/
fs/
http/
path/
streams/
testing/
toml/
yaml/

The full set runs to around fifty and covers more ground than a typical standard library: `msgpack`, `cbor`, `webgpu`, `media_types`, `front_matter`, `data_structures`, `ulid`, `ulid`-adjacent identifier packages, `jsonc`, `ini` and `regexp` sit alongside the familiar `http`, `path`, `fs` and `streams`. That breadth is the reason the library reads as a toolkit rather than a runtime shim.

Two files at the tree root are worth noticing because they signal how the project has grown. `AGENTS.md` is an agent instruction file checked into the repository, and `Releases.md` sits next to it as the human-facing release log. There is also a `deno.json` at the root and a separate `browser-compat.tsconfig.json`, which suggests browser compatibility is verified as a configuration rather than left to chance.

deno.land/std is frozen at 0.224.0 and JSR took over

The most consequential line in the README is an alert block near the top: newer versions of the standard library are hosted on JSR, while older versions up to 0.224.0 remain available at deno.land/std. That is a migration boundary, and it is dated rather than open ended.

Anyone with an existing codebase importing `https://deno.land/std/...` is on the old side of that line. Those versions still resolve, but they no longer receive work. The fix is a change of specifier from a URL to a JSR scope reference, which is a per-import edit rather than a rewrite.

The related shift is the badge. A note explains that this repository used to host the badge SVG file and now retrieves it directly from Shields.io, so the old `badge.svg` still sitting in the tree is a leftover rather than the current source of truth.

<a href="https://jsr.io/@std">
  <img
    width="135"
    height="20"
    src="https://img.shields.io/badge/Built_with_std-black?logo=deno"
    alt="Built with the Deno Standard Library"
  />
</a>

The markdown form is published alongside it, and the package list, architecture guide, design documentation, contributing guidelines and FAQ are all linked from the README's resources section rather than inlined.

Semantic versioning below 1.0.0 has its own rule

The releases section is two sentences and both matter. Package versions at or above 1.0.0 follow Semantic Versioning, and package versions below 1.0.0 follow a separate semver proposal rather than the classic rules. That second clause is the one that changes how you read a changelog entry.

Look at the release-2026.07.30 notes for what that means in practice. `@std/yaml` went to 1.2.0 as a minor with a new `YamlSyntaxError` carrying structured position info. `@std/xml` went to 0.2.0 as a minor, and the same entry is labelled BREAKING. Under classic semver a minor would not break you; under the pre-1.0 rule the project applies, it can.

So the version number alone does not tell you whether an upgrade is safe. The release notes do, and they are detailed enough to be worth reading: the same release deprecates `load()` and `loadSync()` in `@std/dotenv`, deprecates `assertSnapshot()`, `createAssertSnapshot()` and `serialize()` in `@std/testing`, deprecates the `bdd` and `unstable-bdd` modules, adds an `HttpError` to the unstable half of `@std/http`, and removes quadratic buffering from `TextLineStream`.

That is one release touching nine packages with a mix of fixes, features, deprecations and a breaking cleanup. It is the clearest evidence of how the per-package versioning works in practice.

The unstable tier is where new API lands first

Release notes across the three most recent tags are full of `unstable` markers, and the pattern is consistent: a feature appears under an unstable entry point, is used, and is later stabilized in a subsequent release.

From release-2026.06.30: `Channel` in `@std/async` was stabilized as version 1.5.0, `zip` in the unstable half of `@std/collections` learned to accept an `Iterable`, and the index argument in the iterable methods was stabilized at version 1.3.0. `IndexedHeap` in `@std/data-structures` was reworked with a `set()` upsert and generic priorities, and `@std/http` split `parseProblemDetails`, added status validation and a `statusText` option.

The same release carries a fix that says more about priorities than any feature: `@std/path` was changed to improve Node.js compatibility, with the test suite now run in Node and Bun. That is a portability commitment stated as a changelog line, and it is the kind of thing that quietly decides whether a package is usable outside Deno.

The practical read for a consumer is that the unstable entry points are where you should look first if you want something new, and the version numbers tell you how far a given API has been carried.

Licensing, contribution and where the decisions are written down

The repository is MIT licensed, which is unremarkable but worth stating because the project hosts code that a great many Deno applications depend on indirectly. The README is deliberately short: it points to `.github/ARCHITECTURE.md` for both the architecture guide and the design documentation, to `.github/CONTRIBUTING.md` for contribution rules, and to `.github/FAQ.md` for the questions that come up repeatedly.

That is the shape of a mature multi-package project. The README answers where things live and how versions work, and the linked documents answer how to add a package and what the design rules are. For anyone about to propose a new `@std` package, the architecture guide is the file to read first.

The badge is the one piece of documentation-as-markdown in the repository, and the repository dogfoods it: the badge on the page links to JSR and reads Built with std.

[![Built with the Deno Standard Library](https://img.shields.io/badge/Built_with_std-black?logo=deno)](https://jsr.io/@std)

The topics listed for the repository are just denoland, javascript and typescript, and the source language is TypeScript. The open issue count sits above three hundred, which is unremarkable for a repository of this size and release frequency, and the default branch is `main`.

Choosing between std, a runtime built-in and Node's modules

The honest comparison is not with Node's standard library, because the two solve different problems. Deno's runtime already ships web-standard APIs such as `fetch`, `URL` and the stream primitives. What `@std` adds is the layer Node has historically provided: file system walking, path manipulation, assertion helpers, test runners, dotenv parsing, and the format parsers that no runtime ships.

So the decision per package is straightforward. If the runtime already has it, use the runtime, because `@std` deliberately does not duplicate the whole web platform. If you need something Node users would have installed from npm, `@std` is the answer, and each package is a small dependency rather than a monolith.

Two habits follow from the versioning model. Pin the versions, because a monthly release can move nine packages at once and a pre-1.0 minor can break you. And read the release notes before upgrading anything marked 0.x, which covers `dotenv`, `xml` and several others in the current release set.

What you give up by not using `@std` for a task is stability signalling in the pre-1.0 packages. What you get is a standard library that is versioned, documented and released on a schedule rather than accumulated as unversioned URLs.

Editorial conclusion

denoland/std is now a package collection rather than a single library, and that is the fact most people still get wrong. Imports point at `jsr:@std/...`, each package carries its own version, and a release can bump `@std/yaml` to a new minor without touching `@std/path`. The README is short because the interesting decisions live in `.github/ARCHITECTURE.md`, `.github/CONTRIBUTING.md` and `.github/FAQ.md`. The last push was on 2026-09-17 with a release on 2026-07-30, so the cadence is monthly and per package. Pin the versions you depend on, expect deprecation notices to mean an unstable API graduated, and treat the 0.x packages as the ones still moving fastest.

Frequently asked questions

Official sources

1. denoland/std on GitHub
2. License: MIT
3. Project website
4. README
5. Releases