The Standard Library (std) aims to provide high-quality, reliable APIs for fearless use in JavaScript and TypeScript projects. For some time, how and when std would reach stability has been in question. Now, thanks to JSR and workspaces functionality in the Deno runtime, we have a path forward.

What stabilization will look like

Currently, std acts as a single module with a single version, meaning a user may be inclined to upgrade, even if a release doesn't affect the sub-module they use.

After stabilization, new std packages will be exclusively hosted on JSR as separate packages with independent versions. Deno's workspaces functionality allows us to treat each top-level subdirectory as its own package and better adhere to Semantic Versioning. Dependencies become more manageable by only requiring an upgrade for the packages you use, not the entire std module.

More importantly, independent versioning allows us to work on stabilizing packages asynchronously. We can stabilize more established packages while preparing other packages for stabilization. In other words, we can progressively deliver stable packages for the community sooner rather than later.

These changes will also mean we will release std packages independently of Deno runtime releases.

How we'll achieve stability

Step 1 - Decouple std from the runtime (complete)

deno and deno_std are now effectively decoupled, so releasing them in tandem is not required. The remaining point of friction is apiland_scripts, which generates docs. We now have two separate GH Actions in apiland_scripts that can be run independently (release CLI and release STD). These actions can be run independently, and it's a matter of deciding if we do the "split".

Step 2 - Publish exclusively to JSR (complete)

At the moment, std is published to deno.land/std as-is, then converted into a JSR-compatible form in CI and published to JSR as separate packages under the @std scope. Once the previous step is complete, the codebase can be permanently converted into its JSR-compatible form, providing the granular package versioning for the next step.

Note: For the foreseeable future, deno.land/std will remain online and accessible until the version before the JSR cutover is complete.

Step 3 - Stabilize packages asynchronously (in progress)

Once std is entirely cut over to JSR and packages become more stable, we can begin stabilizing packages. A package will only be stabilized once strict criteria are met that guarantee its quality. These will require that each package is:

1. Reviewed and approved with sufficient consensus
2. Tested for maximum coverage
3. Fully documented and well-designed
4. Void of any ongoing issues or known bugs
5. Well supported across many versions of the Deno runtime

Each package follows the stabilization process defined in #4661

Current work

Work towards stabilizing each package is already in progress. This work includes:

• Completing documentation (tracking: complete documentation #3764)
• Increasing test coverage (tracking: improve test coverage #3713)
• Fixing bugs and adding missing features
• Closing issues and PRs
• Improving API design

You can track the stability status of each package here:

Excluded Packages

If you'd like to contribute to stabilizing the Standard Library in any of this work, please feel free to let us know, either on GitHub or Discord. All contributions are welcome and very much appreciated.

Stabilization process

Each package must go through the following steps to achieve stabilization:

1. Publish version 1.0.0-rc.1 once meeting the following requirements:
   1. Approved by at least 2 maintainers. There must be a consensus that the design, documentation, and implementation of the package are good and that it is unlikely to undergo breaking changes in the future.
   2. 100% documented, passing deno doc --lint checks and adhering to the documentation guidelines.
   3. Maximum reasonable test coverage
   4. There are no open issues or pull requests that might lead to breaking changes. For example, issues that suggest new non-breaking features are fine to exist at stabilization.
2. Allow 3 weeks for the community and the core team to review the package and handle any feedback. There must be a consensus that the design, documentation, and implementation of the package are good and it is unlikely to undergo breaking changes in the future.
3. If there are no remaining issues, publish version 1.0.0. If there are remaining issues, extend the waiting period to allow further time for a resolution. Then, repeat this step.

Reference: The dependency graph

The diagram below describes the dependencies between packages. The bottom packages (more dependent packages) usually need to be stabilized earlier than the top packages (more dependent packages).