惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
The GitHub Blog
The GitHub Blog
F
Fortinet All Blogs
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Simon Willison's Weblog
Simon Willison's Weblog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
Cisco Talos Blog
Cisco Talos Blog
P
Privacy & Cybersecurity Law Blog
I
Intezer
Y
Y Combinator Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
N
Netflix TechBlog - Medium
The Hacker News
The Hacker News
AWS News Blog
AWS News Blog
aimingoo的专栏
aimingoo的专栏
A
About on SuperTechFans
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
Stack Overflow Blog
Stack Overflow Blog
Hacker News: Ask HN
Hacker News: Ask HN
酷 壳 – CoolShell
酷 壳 – CoolShell
量子位
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
B
Blog
T
Tor Project blog
C
Cybersecurity and Infrastructure Security Agency CISA
云风的 BLOG
云风的 BLOG
博客园_首页
V2EX - 技术
V2EX - 技术
T
Threat Research - Cisco Blogs
腾讯CDC
宝玉的分享
宝玉的分享
博客园 - 叶小钗
罗磊的独立博客
S
Securelist
The Last Watchdog
The Last Watchdog
Google Online Security Blog
Google Online Security Blog
Scott Helme
Scott Helme
博客园 - 司徒正美
W
WeLiveSecurity
有赞技术团队
有赞技术团队
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
S
Secure Thoughts
NISL@THU
NISL@THU
N
News and Events Feed by Topic
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
雷峰网
雷峰网
大猫的无限游戏
大猫的无限游戏
K
Kaspersky official blog
IT之家
IT之家

Deno

Deno 2.8 | Deno Claw Patrol: an open-source security firewall for agents | Deno Fresh 2.3: Zero JS by default, View Transitions, and Temporal support | Deno Deno 2.7: Temporal API, Windows ARM, and npm overrides | Deno Build a dinosaur runner game with Deno, pt. 6 | Deno Build a dinosaur runner game with Deno, pt. 5 | Deno Deno Deploy is Generally Available | Deno Introducing Deno Sandbox | Deno Build a dinosaur runner game with Deno, pt. 4 | Deno Build a dinosaur runner game with Deno, pt. 3 | Deno Build a dinosaur runner game with Deno, pt. 2 | Deno React / Next.js Denial-of-Service Vulnerability: Deno Deploy users protected | Deno Deno 2.6: dx is the new npx | Deno Build a dinosaur runner game with Deno, pt. 1 | Deno React Server Functions / Next.js Vulnerability: Deno Deploy users protected | Deno My highlights from the new Deno Deploy | Deno Deno's Other Open Source Projects | Deno How Deno protects against npm exploits | Deno Help Us Raise $200k to Free JavaScript from Oracle | Deno Deno 2.5: Permissions in the config file | Deno Fresh 2.0 Graduates to Beta, Adds Vite Support | Deno Deno 2.4: deno bundle is back | Deno JavaScript™ Trademark Update | Deno What's coming to JavaScript | Deno A brief history of JavaScript | Deno Reports of Deno's Demise Have Been Greatly Exaggerated | Deno An Update on Fresh | Deno How Plaid migrated 100 services to a new database platform 5x faster with Deno | Deno Deno 2.3: Improved deno compile, local npm packages, and more | Deno Add JSR packages with pnpm and Yarn | Deno Zero-config Debugging with Deno and OpenTelemetry | Deno Exploring Art with TypeScript, Jupyter, Polars, and Observable Plot | Deno Deno v Oracle Update 3: Fighting the JavaScript Trademark | Deno Build a custom RAG AI agent in TypeScript and Jupyter | Deno How to get deep traces in your Node.js backend with OTel and Deno | Deno toranoana.deno #20 登録受付中(2025年3月14日) | Deno Node just added TypeScript support. What does that mean for Deno? | Deno The Dino 🦕, the Llama 🦙, and the Whale 🐋 | Deno Publish a lint rule, get a prize | Deno Deno 2.2: OpenTelemetry, Lint Plugins, node:sqlite | Deno If you're not using npm specifiers, you're doing it wrong | Deno How Deno's documentation is evolving | Deno Oracle justified its JavaScript trademark with Node.js—now it wants that ignored | Deno Introducing the JSR open governance board | Deno Intro to Wasm in Deno | Deno Announcing OpenAI on JSR | Deno Deno in 2024 | Deno Goodbye WinterCG, welcome WinterTC | Deno Build a SolidJS app with Deno | Deno Run your Next.js SSR app on Deno Deploy | Deno Solve Advent of Code 2024 with Deno and Win Prizes! | Deno Deno v. Oracle: Canceling the JavaScript Trademark | Deno Deno 2.1: Wasm Imports and other enhancements | Deno Build a Typesafe API with tRPC and Deno | Deno Self-contained Executable Programs with Deno Compile | Deno Build a Database App with Drizzle ORM and Deno | Deno Introducing your new JavaScript package manager: Deno | Deno Announcing Growthbook on JSR | Deno Build an Astro site with Deno | Deno How to convert CommonJS to ESM | Deno Announcing Deno 2 | Deno The Final Touches: What’s New In v2.0.0-rc.10 | Deno Announcing Stable V8 Bindings for Rust | Deno Deno 2.0 Release Candidate | Deno Secure, efficient private npm registries with Cloudsmith and Deno | Deno Painting the Plane as We Fly It: Designing JSR | Deno Introducing Web Cache API support on Deno Deploy | Deno Deno 1.46: The Last 1.x Release | Deno Protect your cloud spend with new Deno Deploy spend limits | Deno What we got wrong about HTTP imports | Deno Benchmarking AWS Lambda Cold Starts Across JavaScript Runtimes | Deno Announcing Supabase on JSR | Deno Deno 1.45: Workspace and Monorepo Support | Deno Introducing KV Backup for Deno Subhosting | Deno A Gentle Intro to TypeScript | Deno Announcing Hono on JSR | Deno How We Made the Deno Language Server Ten Times Faster | Deno How the Guardian uses Deno to audit accessibility and performance across their 2.7 million articles | Deno Introducing More Flexible Domain Association for Deno Subhosting | Deno The stabilization process of the Standard Library has begun | Deno Deno 1.44: Private npm registries, improved Node.js compat, and performance boosts | Deno How we built a secure, performant, multi-tenant cloud platform to run untrusted code | Deno How to document your JavaScript package | Deno Your Low Code Solution Needs an Escape Hatch | Deno Deno 1.43: Improved Language Server performance | Deno How Slack used Deno to save months of engineering effort in launching their new platform | Deno JSR Is Not Another Package Manager | Deno Announcing the Hookdeck SDK on JSR | Deno Announcing the Neon Serverless Driver on JSR | Deno An intro to TSConfig for JavaScript Developers | Deno How we built JSR | Deno How Netlify used Deno Subhosting to build a successful edge functions product | Deno Introducing Simpler Project Creation in Deno Deploy | Deno Deno 1.42: Better dependency management with JSR | Deno Introducing deployctl, the command line interface for Deno Deploy | Deno Introducing JSR - the JavaScript Registry | Deno How to add Monaco to a Next.js app and securely run untrusted user code | Deno Survey Results and Roadmap | Deno Deno 1.41: smaller deno compile binaries | Deno Webhooks suck, but here are alternatives | Deno
The Deno Standard Library is now available on JSR | Deno
2024-05-15 · via Deno

We are excited to announce a significant evolution in the Deno ecosystem: the Deno Standard Library, a robust collection of high-quality TypeScript packages, has officially moved to JSR, the new JavaScript package registry.

Since the early days of Deno, the Standard Library has been a cornerstone at https://deno.land/std, featuring essential packages ranging from file system management to advanced cryptographic functions. These packages are all audited by the Deno team and guaranteed to work with Deno.

JSR is not another package manager; it’s a forward-thinking registry designed to unify and simplify JavaScript package distribution across different environments. Built to seamlessly integrate with Deno and other JavaScript runtimes, JSR introduces a number of features that significantly enhance the JavaScript ecosystem. Its compatibility extends to environments like Node.js, Cloudflare Workers, and even browsers using bundlers, ensuring a broad spectrum of JavaScript applications can leverage Deno’s Standard Library.

With the transition to https://jsr.io/@std, JSR now hosts the Standard Library, providing autogenerated documentation and SemVer deduplication while enhancing accessibility and versatility for developers worldwide.

Using the Standard Library on JSR

To install the packages, use the following command:

deno add @std/fs @std/path

This command updates your deno.json import map as shown below:

{
  "imports": {
    "@std/fs": "jsr:@std/fs@^0.224.0",
    "@std/path": "jsr:@std/path@^0.224.0"
  }
}

You can then import these packages in your source code:

import { copy } from "@std/fs";
import { join } from "@std/path";

await copy("foo.txt", join("dist", "foo.txt"));

Alternatively, you can import directly using a jsr: specifier:


import { copy } from "jsr:@std/fs@^0.224.0";
import { join } from "jsr:@std/path@^0.224.0";

await copy("foo.txt", join("dist", "foo.txt"));

Node.js and beyond

JSR’s compatibility with npm allows you to use the Deno Standard Library in Node.js, Cloudflare Workers, and browsers with bundlers. For example, running this command

npx jsr add @std/async @std/collections

will add dependencies to your package.json:

 {
   "dependencies": {
+    "@std/async": "npm:@jsr/std__async@^0.224.0",
+    "@std/collections": "npm:@jsr/std__collections@^0.224.0"
   }
 }

You can now use these packages as shown below:

import { delay } from "@std/async";
import { deepMerge } from "@std/collections";

await delay(100);

console.log(deepMerge({ foo: { bar: 1 }, baz: 2 }, { foo: { qux: 2 } }));

Run this script with Node.js:

$ node main.mjs
{ foo: { bar: 1, qux: 2 }, baz: 2 }

Currently, about 70% of the Standard Library packages are compatible with Node.js. You can look at the compatibility icons in the package list on https://jsr.io/@std to see which packages are compatible with Node.js.

Note: The Standard Library is only distributed as ES Modules. Any script that uses the Standard Library needs to be an ES Module. This means your files either need to have the .mjs file extension, or the project’s package.json needs to have a "type": "module" property.

Independent versioning for each Standard Library package

The Deno Standard Library is now organized into 37 distinct packages, such as @std/fs and @std/path.

The decision to version different parts of the Standard Library individually was driven by the varied maturity, complexity, and usage of its components. Some parts of the library, like @std/fs, are mature and undergo fewer changes, already being widely used in numerous real-world applications. In contrast, newer additions, such as @std/expect—which is only four months old—are still in the early stages of adoption and development.

Previously, the diverse maturity levels within the Standard Library posed a significant challenge to its stabilization. It was impractical to apply a one-size-fits-all approach to the entire library, given the broad spectrum of maturity across its components.

By adopting independent versioning for each package, we can stabilize mature packages promptly while continuing to refine and experiment with the less mature ones. This strategy not only accelerates the stabilization of the standard library but also maintains the flexibility needed to evolve it further.

Leveraging Deno workspaces

We manage interdependencies among @std packages using Deno’s brand new workspaces feature. This feature helps packages depend on each other locally without needing to publish each one.

The workspaces feature is still under development. In particular, LSP support for it is still to be added. If you’re interested in its development progress, check out and subscribe to the tracking issue.

The workspaces feature is enabled by defining the "workspaces" field in deno.json. Let’s take a look at the deno.json of the Standard Library repository:

{
  "workspaces": [
    "./archive",
    "./assert",
    "./async",
    "./bytes"
    // ...
  ]
}

Notice that, for example, @std/archive depends on @std/assert (ref):

import { assert } from "@std/assert/assert";

...
assert(fileSize !== undefined, "fileSize must be set");
...

The assert function is directly imported from the local ./assert directory in the repository instead of the published version. The Standard Library still works like a single source code despite each of the packages being published independently.

Future of deno.land/std

deno.land/std will still be available indefinitely. All programs that depend on deno.land/std will keep working. Don’t worry!

However, going forward new features will be published to jsr.io/@std. deno.land/std will receive only critical updates, such as security patches.

Migrating from deno.land/std to jsr:@std

If you currently use the Standard Library from deno.land/std, we recommend you upgrade to importing from jsr:@std.

To upgrade to jsr:@std, we first recommend upgrading your deno.land/std version to 0.224.0:

- import { join } from "https://deno.land/std@0.170.0/path/mod.ts";
+ import { join } from "https://deno.land/std@0.224.0/path/mod.ts";

Then update the HTTP specifier to the JSR specifier:

- import { join } from "https://deno.land/std@0.224.0/path/mod.ts";
+ import { join } from "jsr:@std/path@0.224.0";

That’s it!

Looking ahead

The Standard Library is still at v0.x versions, which means that the APIs are not yet stabilized. We plan to stabilize the Deno Standard Library on a package-by-package basis. The first candidates for stabilization are @std/bytes and @std/collections. For updates, follow this issue (denoland/deno_std#4600).

As we move forward, we’re excited about the possibilities that JSR opens up for developers across the globe. Join us in embracing this new phase in JavaScript development.