Deno 2.0 Release Plan

[kitsonk]

Schedule

• No deadline yet planned.

Scope

Note, at this stage it is still subject to change as items get better refined. This is a working list.

• Move JavaScript only "stuff" out of the Deno Namespace (Remove pure JS (non native) io functions from Deno namespace #9795)
• Enable Deno namespace by default in workers (Enable Deno namespace by default in Workers #8174)
• Don't type check be default (Skip type checking by default #11340)
• New subprocess API (Implement new two-tier subprocess API #11016, Detached processes in deno #5501, feat(runtime): two-tier subprocess API #11618)
• JSON Modules (Import Assertions/JSON Modules #7623)
• Turn TypeScript useUnknownInCatchVariables on (Enable "useUnknownInCatchVariables" for TypeScript by default #11826)
• Remove deprecated Deno.customInspect (Remove Deno.customInspect symbol at 2.0 #10929)
• Lockfile generated by default (Lockfile should be written by default #11971)
• op metrics refactoring/cleanup (op metrics refactoring/cleanup #12109)
• Switch JSX/TSX default constructors (Proposal: [breaking-change] Default to h and Fragment for JSX #11186)
• Remove Deno.read() and Deno.write() (Remove "standalone" resource method from Deno namespace #12107)
• Have a single configuration for TypeScript (Investigate "single" TypeScript Configuration #12111)
• Internal Origin for Persistance (Internal Origin for Persistence #11882)
• Don't report check diagnostics for external scripts by default (Don't report diagnostics for "external" TypeScript code #11970)
• Use --allow-import for dynamic imports and workers (Proposal: add --allow-import=<allow_list> for checking dynamic imports/workers #8266)
• NotCapable error to distinguish between permissions and capabilities (Introduce a "NotCapable" error #7394)
• Remove --ts flag (it was redundant with --ext) (BREAKING(cli/eval): remove --ts flag #12198)

[nayeemrmn]

Has #10628 been considered?

[kitsonk]

@nayeemrmn yes, including just eliminating the subcommand entirely, in the discussions there was no clear path forward, nor did we evaluate it as having a significant upside in terms of usability, so we just put it aside.

[kitsonk]

Folks, this is not the place to discuss Deno release strategy. Please use the discussion topics if you wish to that. This issue is for tracking a planned release. I have marked comments off topic because of this.

[ry]

We've decided to postpone the 2.0 deadline because there are some critical bits we want to figure out still which have uncertain timelines:

• Should CLI have addEventListener("fetch", _) support out-of-the-box so it can interoperate with Cloudflare Worker and Deno Deploy scripts?
• Node compatibility (--compat)
• How does backwards compatibility and effort towards a Deno configuration file interact? Does a default --location interact well with a package.json project directory structure?

I'm going to unpin this issue but leave it open. We do have breaking changes we want to make and will address them - but not yet in November.

[amithm7]

@ry

Should CLI have addEventListener("fetch", _) support out-of-the-box so it can interoperate with Cloudflare Worker and Deno Deploy scripts?

• I see that deployctl was archived. So, is the FetchEvent support coming?

@lucacasonato 's archiving comment:

You can now run your Deploy scripts with deno run: deno.com/deploy/docs/running-scripts-locally

• Doesn't make sense as it requires changes to the script, to create an http server.
• As it says in the deno deploy docs, the API of deno and deno deploy differ: https://deno.com/deploy/docs/runtime-api/
• Deno also hasn't implemented the Service Worker API, which I am guessing what Deno Deploy is based on? Implement the Service Worker API #5957
• I was about to use deployctl in production, thinking https://deno.com/deploy/ is powered by that. So what's the idea here?

[vwkd]

• Should CLI have addEventListener("fetch", _) support out-of-the-box so it can interoperate with Cloudflare Worker and Deno Deploy scripts?

@ry I opened denoland/deploy_feedback#107 arguing why designing for compatibility with another service is not a good idea. Irrespective of the why, Cloudflare is transitioning away from the service worker syntax addEventListener("fetch", _) anyways to a default class export with a fetch method ¹. Adding this now is just hurting yourself.

Footnotes

1. export default { async fetch(request, env) { … } } in a .mjs file. Source: https://developers.cloudflare.com/workers/learning/using-durable-objects#instantiating-and-communicating-with-a-durable-object ↩ ↩

[bartlomieju]

Deno 2.0 was postponed indefinitely. I'm going to close this issue to avoid confusion about expected feature set and dates. We will open a new issue when the plan clarifies.