Last 12 weeks · 98 commits
4 of 6 standards met
currently holds both lightweight async helpers and heavier concurrency primitives. As the latter group grows, the module name stops describing its contents well. The concurrency items are categorically different from the rest of the module, they should get their own package. The concurrency module is about coordinating shared access to resources. This mirrors the and split that was done. The split is clean: , (in the works), , and have no internal dependencies on other files. These are low-level synchronisation primitives. All four are still unstable, so there should be no deprecation overhead. "Concurrency primitives" is a well-understood category, and it gives the new package a natural growth path (e.g. , , ...) without further bloating . I renamed the files, since the new module itself is unstable.
Repository: denoland/std. Description: The Deno Standard Library Stars: 3531, Forks: 666. Primary language: TypeScript. Languages: TypeScript (96.1%), JavaScript (3.6%), Rust (0.3%). License: MIT. Homepage: https://jsr.io/@std Topics: deno, javascript, typescript. Latest release: release-2026.02.20 (1w ago). Open PRs: 30, open issues: 228. Last activity: 1d ago. Community health: 87%. Top contributors: iuioiua, kt3k, timreichen, bartlomieju, ry, denobot, caspervonb, nayeemrmn, kitsonk, lino-levan and others.
TypeScript
Prevent from crashing when a or tag is missing by adding early returns, matching the guards already used by and .
I'm wondering whether anybody has looked more into this. says it's "ported from js-yaml v3.13.1" e18e says "js-yaml appears to be unmaintained and has known spec-compliance issues." They recommend instead, which is also availabe on JSR as @eemeli/yaml So, should new projects better use ? Perhaps should be changed to be a thin wrapper around ? Or am I missing something, does the current code-base have other benefits?