Skip to content

denoland/deno_std

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Deno Standard Library

JSR @std codecov ci

High-quality APIs for Deno and the web. Use fearlessly.

Note

Newer versions of the Standard Library are now hosted on JSR. Older versions up till 0.224.0 are still available at deno.land/std.

Packages

The following list contains links to the Standard Library's packages and documentation:

Package Status Latest version
archive Unstable JSR
assert Settled JSR
async Settled JSR
bytes Settled JSR
cli Unstable JSR
collections Settled JSR
crypto Settled JSR
csv Settled JSR
data_structures Unstable JSR
datetime Unstable JSR
dotenv Unstable JSR
encoding Settled JSR
expect Unstable JSR
fmt Settled JSR
front_matter Settled JSR
fs Settled JSR
html Unstable JSR
http Unstable JSR
ini Unstable JSR
io Unstable JSR
json Settled JSR
jsonc Settled JSR
log Unstable JSR
media_types Settled JSR
msgpack Unstable JSR
net Unstable JSR
path Settled JSR
regexp Unstable JSR
semver Unstable JSR
streams Settled JSR
testing Settled JSR
text Unstable JSR
toml Settled JSR
ulid Unstable JSR
url Unstable JSR
uuid Settled JSR
webgpu Unstable JSR
yaml Settled JSR

Note: Settled status means a package is unlikely to have breaking changes, but has not yet achieved v1 status.

Stabilization

The Standard Library is now in the process of stabilizing its packages. Below is the current schedule:

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 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 possible test coverage
    4. 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 1 month for the community and the core team to review the package and handle any feedback. There must be consensus that the design, documentation and implementation of the package are good and that 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.

Architecture

Check out the architecture guide here.

Design

Minimal Exports

Files are structured to minimize the number of dependencies they incur and the amount of effort required to manage them, both for the maintainer and the user. In most cases, only a single function or class, alongside its related types, are exported. In other cases, functions that incur negligible dependency overhead will be grouped together in the same file.

Contributing

Check out the contributing guidelines here.

Releases

New versions of packages are published every 1 or 2 weeks. Package versions

=1.0.0 follow Semantic Versioning, and package versions <1.0.0 follow this proposal.

Badge

Built with the Deno Standard Library

<a href="https://jsr.io/@std">
  <img
    width="135"
    height="20"
    src="https://raw.githubusercontent.com/denoland/deno_std/main/badge.svg"
    alt="Built with the Deno Standard Library"
  />
</a>
[![Built with the Deno Standard Library](https://raw.githubusercontent.com/denoland/deno_std/main/badge.svg)](https://jsr.io/@std)

Frequently Asked Questions

Check out the frequently asked questions page here.