Deno: Standard Library Working Group

[ry]

The standard library in Deno has seen a lot of growth and improvement over the past year. We think it is time to review and stabilize these APIs, guaranteeing that users will not experience painful changes in the future. In order to avoid cementing mistakes, we want to review these APIs, one-by-one, and come to a consensus on whether they should be included, modified, or excluded.

We will be holding a series of virtual events every two weeks. We will (perhaps tediously 😄 ) review APIs and hear any objections. Because there are so many APIs to review, this will take place over several months.

In order to accommodate people in different timezones, we will have an alternating timing schedule.

This issue will remain pinned and this message updated as we work through each of the modules. If you would like to participate, please email [email protected] to be invited to the event.

December 3 (14:00-16:00 GMT)

• archive
• async
• bytes

December 17 (Time TBD)

• datetime
• encoding
• flags

January 7 (time TBD)

• fmt
• fs
• hash

January 21 (time TBD)

• http
• io
• log

February 4 (time TBD)

• mime
• node
• path

February 18 (time TBD)

• permissions
• signal
• testing

March 4 (time TBD)

• textproto
• uuid
• wasi
• ws

[bartlomieju]

Important topic to discuss (preferably sooner than later) is std versioning. We won't stabilize all APIs and there will be new APIs added in the future, therefore we should establish some convention similar to --unstable flag for built-in Deno APIs.

[MarkTiedemann]

Another important topic to discuss (and write down) is the boundaries between core, std, and third-party modules. What are the criteria for APIs to be included in core? In std?

For example, in Node, the HTTP server is in core. Why is it in std in Deno? In Node, a TOML parser is a third-party module. Why is it in std in Deno?

I think having clearly defined boundaries between these realms would be helpful.

[hazae41]

Another important topic to discuss (and write down) is the boundaries between core, std, and third-party modules. What are the criteria for APIs to be included in core? In std?

For example, in Node, the HTTP server is in core. Why is it in std in Deno? In Node, a TOML parser is a third-party module. Why is it in std in Deno?

I think having clearly defined boundaries between these realms would be helpful.

• core aims to implement Web APIs and includes the native stuff
• std aims to standardize common modules
• third-parties are modules that don't fit in std

While Node is battery-included, Deno aims to be minimalist in its packaging

This is all explained here https://deno.land/[email protected]/runtime

[MarkTiedemann]

@hazae41 I don't intend to discuss this topic now, I merely want to show that a discussion may be warranted.

core aims to implement Web APIs and includes the native stuff

• Deno.test and Deno.inspect aren't Web APIs.
• Deno.iter and Deno.copy don't use "native stuff".

So yes, while "Web APIs" and "native APIs" are included in core,

• only a subset of Web APIs is included in core,
• only a subset of native APIs is included in core, and
• APIs that are neither Web APIs nor native APIs are also included in core.

std aims to standardize common modules

• MuxAsyncIterator from std/async isn't a "common API" when searching for it on Google - there aren't even 1000 results.
• printf from std/fmt may be a common API in C, but is it a common API in JS development?
• There's APIs for tar in std/archive. Why are there no APIs for zip? Is tar common but zip uncommon?

"common modules" is a very subjective definition.

[timreichen]

Agree with @MarkTiedemann to define clear boundaries. There seems to be lots of different ideas of what std is/should be.
I would like to mention, that it is a mix of mods with specification and mods that seem to fall more in the category of utility or convention atm.
Maybe the modules could be split in std for mods with specs (tar, hash, encoding, etc.), util (or something along those lines) for mods like log, fmt, async, node, etc. to have something between std and 3rd party?

@ry Shouldn't the title be Standard Module Working Group?😉