Deno: 1.0

[ry]

Update April 15, 2020: Still go for May 13.

Update March 6, 2020: There's a difficult balance to be had between trying to get it right and shipping a usable product. The repository continues to see rapid development and we have yet to make substantial progress on the major missing feature: dev tool support. Therefore we are bumping the release date yet again. However instead of blindly estimating several weeks out, we've discussed it at length and decided 2 months would be enough time. This coincidentally is around the 2 year anniversary since the first commit. Therefore we are setting the date of May 13, 2020 as the 1.0 release date. Contributors are encouraged to get any major API changes in before April 20 - after that date we will be polishing and bug fixing. Of course the API will continue to evolve and improve after 1.0, but we will be making explicit stability guarantees for some interfaces.

Update Jan 27, 2020: Massive progress is being made, but we still have not yet accomplished the major feature blocker: devtool support. I hate to keep kicking the release date, but we're still looking at some weeks of development. We hope to ship a 1.0 build with stability promises towards end of February.

Update Dec 23, 2019: There is one major feature we lack that needs to be in 1.0 - that's a way to hook Deno up to Chrome DevTools. Implementing it has induced a rewrite of the bindings to V8 - that work is ongoing https://github.com/denoland/rusty_v8. We want to fork lift Deno onto that system before 1.0 happens. Current estimate for 1.0 is end of January.

• [x] replace libdeno with rusty_v8 https://github.com/denoland/deno/issues/3530

• [x] "deno --debug" https://github.com/denoland/deno/issues/1120 We need to be able to debug using Chrome Devtools. As the deno userland code base grows, it becomes in increasingly painful to work without a debugger. The way this will work is with a websocket server in Rust (port 9229) which forwards messages to V8 (using V8InspectorClient). https://github.com/denoland/deno/pull/4484

• [x] Loading and execution of modules (either JS or TS) needs to be correct. This is the main thing we deliver actually, but there are still many bugs: source maps are sometimes incorrect https://github.com/denoland/deno/issues/2390, double downloads happen https://github.com/denoland/deno/issues/2442, the cache needs to be refactored https://github.com/denoland/deno/issues/2057.

• [X] Import maps. It's a very reasonable standard and we can provide support via a command line flag. This allows bare imports. The feature will land very soon https://github.com/denoland/deno/pull/2360.

• [x] Dynamic import. 50% complete at the time of writing. https://github.com/denoland/deno/issues/1789

• [x] "deno test" test runner https://github.com/denoland/deno_std/issues/193

• [x] "deno fmt" is slow on the first run. It download a couple of large prettier bundles. https://github.com/denoland/deno/issues/2490

• [x] We need to support d.ts files https://github.com/denoland/deno/issues/1432

• [X] "deno bundle" outputs a single AMD bundle of your program. This is useful to share code with websites. Early work has started: https://github.com/denoland/deno/pull/2467

• [ ] "deno compile" is a very interesting feature to output an executable. It would be nice to have, but I would let this slip past 1.0. https://github.com/denoland/deno/issues/986 Not for 1.0

• [x] "deno install" is a program that creates little shell script aliases to deno programs in your $PATH. This let's people distribute their code easily. https://github.com/denoland/deno_std/issues/471

• [x] dlopen / plugins / extension modules. We need some way of calling into Rust land. The way Parcel does it is pretty awesome https://parceljs.org/rust.html - but we need low-level primitives to build that on, as we need to carefully funnel everything through the Op abstraction. @afinch7 has a working patch for loading ops in DLLs https://github.com/denoland/deno/pull/2385, we are still iterating on the exact API. I would allow a true FFI module to slip past 1.0 - we'll get there - but it needs to be built on ops. https://github.com/denoland/deno/pull/3372

• [x] Support TLS https://github.com/denoland/deno/issues/3009

• [ ] The web-server should be faster.

• [X] When you visit a deno.land script url (example https://deno.land/std/http/server.ts) in a web browser, it should do better than redirect. It should look at the Accept header and serve pretty HTML. Solved in https://github.com/denoland/registry/commit/b78e6ae331004859aad7b01ed452f6b00265b035

• [X] If you use "docs.deno.land" you will get auto-generated docs. https://github.com/denoland/deno/issues/3094 https://github.com/denoland/deno_website2/pull/49

• [x] typescript dependencies are not loaded in parallel #2626 https://github.com/denoland/deno/issues/2994

• [x] signal handlers https://github.com/denoland/deno/issues/2339 #3757

• [X] fs events https://github.com/denoland/deno/issues/1826 #3452

• [ ] TS and source maps are correctly recompiled https://github.com/denoland/deno/issues/2945

• [x] Remove tokio_util::block_on https://github.com/denoland/deno/issues/2960

• [x] "deno test" is slow (when running on std) https://github.com/denoland/deno/issues/2789

• [x] deno lock file https://github.com/denoland/deno/issues/200

Do any major API renames.

• [X] https://github.com/denoland/deno/issues/2384
• [X] https://github.com/denoland/deno/issues/2474
• [X] https://github.com/denoland/deno/issues/2635 clean up ErrorKinds
• [x] https://github.com/denoland/deno/issues/2767 use web standard Permission API
• [x] https://github.com/denoland/deno/issues/2730 register_op
• [x] https://github.com/denoland/deno_std/issues/562 test(name, fn)
• [x] https://github.com/denoland/deno/issues/2123 Deno.args
• [x] https://github.com/denoland/deno/issues/2934 referencing d.ts files
• [x] https://github.com/denoland/deno/issues/2553 import.meta doesn't work with bundling on browsers. We need to come up with a different scheme for branching if the script is the main.
• [x] https://github.com/denoland/deno/issues/3520 window.location should be cwd?

Other minor bugs that are nevertheless blockers:

• [x] async iteration on fetch bodies https://github.com/denoland/deno/issues/2520
• [x] https://github.com/denoland/deno_std/issues/442
• [x] support onload https://github.com/denoland/deno/issues/2386
• [x] support proxy for module downloads https://github.com/denoland/deno/issues/588 https://github.com/denoland/deno/issues/2873
• [x] panic on too many open files https://github.com/denoland/deno/issues/2243
• [x] we need a way to use typescript compiler from userland https://github.com/denoland/deno_std/issues/428 #2927
• [x] 'url' variable can't be used https://github.com/denoland/deno/issues/2888
• [x] https://github.com/denoland/deno/issues/3367
• [x] https://github.com/denoland/deno/issues/3852 Can't import jspm modules
• [x] #3401 Permissionless static relative imports are dangerous

[95th]

"deno fmt" is slow on the first run. It download a couple of large prettier bundles.

deno fmt right now combines "installation" by loading prettier bundles + formatting.

We can follow Rust's example for this. Rust's cargo fmt is optional but you can download it using rustup component add rustfmt.

We can do something like deno install fmt (using denoland/deno_std#471) which would download the prettier bundles and compile them into cache. Only after this, user should be able to call deno fmt.

Also, is there any existing issue for this?

[ry]

@95th let's move the discussion for fmt to https://github.com/denoland/deno/issues/2490

The other option is to include prettier in the compiler snapshot - which would make it run very fast.

[afinch7]

We also need to address this at some point before 1.0
https://github.com/denoland/deno/blob/76329cf610af1612d4e9c562a1ee3a4dd6082a37/cli/ops.rs#L196

[bartlomieju]

@afinch7 could you explain what's to address with op_fetch_module_meta_data? (preferably in separate issue)

[acconrad]

@ry I'll take this:

When you visit a deno.land script url

Where would the CSS live for that? Where is the website server code within deno?

[afinch7]

@bartlomieju see #1858

[mtharrison]

@acconrad I have a WIP PR open for that https://github.com/denoland/registry/pull/95

[geglock]

Support for "http proxy" (for downloading modules) should also be considered for 1.0. See #588. Otherwise deno is hardly usable in enterprise environments.

[ry]

@geglock Thanks - I will add it to the list.

[nayeemrmn]

Not exactly a feature but issues like #2069 should be closed in one sense or another before 1.0, right? Maybe those could be listed?

[teleclimber]

I presume that supporting other networks such as unix is necessary for 1.0? I haven't seen anything specific about that.

deno/js/net.ts line 8:

export type Transport = "tcp";
// TODO support other types:
// export type Transport = "tcp" | "tcp4" | "tcp6" | "unix" | "unixpacket";

Thanks!

[SerkanSipahi]

@ry

1.) I would like to suggest that if we introduce the --debug mode we also add a hot-reload flag so that the browser will reload when the file has changed.

deno some-file.ts --debug --hot-reload

What do you think?

2.) Do you have any release date for 1.0?

[hayd]

@SerkanSipahi 1.) would be quite a small wrapper around #1826, there's already a couple of issues for it.

[kitsonk]

We have been hesitant for a watch mode. It is more than just a wrapper on FS events, as we need to determine what part of the compilation needs to be invalidated and reloaded. It certainly isn't a 1.0 feature IMO.

[hayd]

we need to determine what part of the compilation needs to be invalidated and reloaded

I don't follow, one could kill completely and restart. Anyway, agree it's not needed for 1.0.

[kitsonk]

I don't follow, one could kill completely and restart. Anyway, agree it's not needed for 1.0.

One could, but that wouldn't be as effective/performant as what we would want to build into Deno, which would invalidate the cache for any changed modules, and potentially only reinsert into the isolate the changed recompiled modules, preserving any running state. That would be hot reloading. Restarting would lose any in memory state of "all" the code, not the code that changed.

[ry]

I'm removing fs-events as a blocker for 1.0. It's certainly important but a must-have.

[andyfleming]

I think https://github.com/denoland/deno/issues/986 should make it into 1.0. It would be pretty useful and is a great differentiator. It also sounds we're not too far off from it.

[andyfleming]

https://github.com/denoland/deno/issues/3155 (a minimum typescript and deno version requirement) should also be considered for 1.0.

[andyfleming]

We also should have some developer experience awareness with 1.0.

One specific aspect of that is editors/IDEs. Specifically we should ensure there's not an issues with working on deno projects in common IDEs.

[kitsonk]

986 would really be a lot to deliver for 1.0... I don't personally think it is critical path. Deno 1.0 is about building a differentiator to drive adoption, it is about having a stable-ish API and a good set of well rounded features, IMO.

[andyfleming]

Fair enough @kitsonk. Also since deno is a single binary and easy to install, it diminishes the importance of #986.

[izelnakri]

@ry currently in node.js v12+ there is experimental worker_threads module that allows users to create a JS thread pool for CPU intensive tasks that can occur in runtime(linting, code-analysis&transpiling, hashing, compressing, encrypting etc). I couldn't find anything similar in plans or in the documentation. Can we add it to this list?

This is a separate request than native plugins.

[bartlomieju]

@ry currently in node.js v12+ there is experimental worker_threads module that allows users to create a JS thread pool for CPU intensive tasks that can occur in runtime(linting, code-analysis&transpiling, hashing, compressing, encrypting etc). I couldn't find anything similar in plans or in the documentation. Can we add it to this list?

This is a separate request than native plugins.

@izelnakri Deno supports web standard Worker API

[ry]

@izelnakri deno already has web workers

[CGQAQ]

@izelnakri Deno is mostly web compatible, any feature that web support, deno most likely would already supported, that's the point of choose Deno over Node.
So if you have any feature wanted but seems don't have deno documents , just try the web way and read the MDN documents side, you will be surprised how many web features deno supported

[kevinkassimo]

We might want to document Workers at least in the manual

[kitsonk]

@ry I would move denoland/deno_std#428 to #2927 and we can "tick" #2888 in the list.

[lucacasonato]

@bartlomieju mentioned the need to rework of the ops signatures for plugins to deliver #3453. That would be a breaking change so it would have to happen before 1.0.

[lucacasonato]

@ry Should #2180 be added to the 1.0 requirements too?

[brandonkal]

Some other features worth considering for 1.0:

• Typescript Compile time is slow. https://github.com/denoland/deno/issues/3111
  Improving caching should improve the "first impressions" for people that will try it out after the annoouncement.
• An "official" Docker image https://github.com/denoland/deno/issues/3356.

[teleclimber]

Could these permission and security related items get looked at before 1.0? I'm a bit worried that it will be hard to address afterwards.

• #3401 Permissionless static relative imports are dangerous
• #2705 Current design of --allow-net

Thanks!

[awkj]

can deno disable some js grammer by denofmt(similar gofmt)? example forbit "var" or "==".

[Aloso]

can deno disable some js grammer by denofmt(similar gofmt)? example forbit "var" or "==".

That's what tslint is for.

[awkj]

can deno disable some js grammer by denofmt(similar gofmt)? example forbit "var" or "==".

That's what tslint is for.

my meaning dont't let it pass compile rahther than warning

[brandonkal]

deno fmt is just a wrapper around prettier. It doesn't compile your code to run. It's best to leave stylistic choices like that to eslint.

[Soremwar]

Is there an issue for "The web-server should be faster." feature?

Also it seems that #2934 is resolved, so "referencing d.ts files" can be ticked.

[brandonkal]

I've opened #3891 to rename RunOptions.args to cmd. This would be a good thing to tackle before 1.0.

[maxmellen]

Should TypeScript strict mode by default for user code (https://github.com/denoland/deno/issues/3324) also be considered for v1.0?

[ShawnTalbert]

Update Jan 27, 2019: Massive progress is being made, but...

This is the first time I've visited this issue, but assume we really meant Jan 27,2020?

[davidroeca]

In response to @andyfleming's comment about developer support:

One specific aspect of that is editors/IDEs. Specifically we should ensure there's not an issues with working on deno projects in common IDEs.

One issue I've come across with TypeScript + deno IDE support is the following issue: https://github.com/microsoft/TypeScript/issues/35749

While deno works fine with these paths, my editor (powered by coc.nvim which itself uses the the tsserver in a way similar to VSCode) gives me issues with URL style imports.

It might be worth working with the TypeScript team to figure out whether they're receptive to resolving this issue, or to find a suitable workaround for most editors.

Happy to open an issue related to this if that's desired.

Edit: found https://github.com/fannheyward/coc-deno

[brandonkal]

@davidroeca Your editor still needs to understand how to resolve a URL to its cache location which is Deno-specific. So this will generally require a TypeScript plugin. You can fix your IDE with for instance: https://github.com/axetroy/vscode-deno/tree/master/typescript-deno-plugin

[brandonkal]

@ry #3919 I assume a working test subcommand is also a 1.0 blocker.

[pnsvinodkumar]

Can anyone please let me know what would be the future of Node ? (any timeline on Deno for 1.0 ?)
What would be the fate of all the mammoth amount of packages (prod-ready) already available for node in the community ? Would there be a clear migration path?

[josephrocca]

Should #3649 (read/write defaults) be resolved before v1.0? It seems pretty important. I'd definitely like --allow-read and --allow-write to not default to being able to read/write anywhere. As pointed out in that issue, it's only two extra characters to type --allow-read=/ if someone wants to give the script full access. Speaking only for myself, most of my use cases would only need to read/write within the current directory (--allow-read=.).

It seems a few people in #3649 are in favor of not having a default - i.e. you need to always specify the read/write directory, which does make sense I think since it's only 2 extra characters most of the time. This would also leave open the opportunity for adding a default later without breaking backwards compatibility. Whereas if the current approach goes ahead for v1.0 and it turns out to be a bad choice, then it will require a significant breaking change.

[somombo]

@pnsvinodkumar Can anyone please let me know what would be the future of Node ? (any timeline on Deno for 1.0 ?) What would be the fate of all the mammoth amount of packages (prod-ready) already available for node in the community ? Would there be a clear migration path?

You can continue using node.js as usual since these are technically independent projects. I think migration guides (if any) will start to emerge once Deno matures and best practices cement (Definitely after v1.0). Finally, current ETA has already been described in the original post (and is actively updated there), so just watch that post in case the expected timeline changes.

[pnsvinodkumar]

@somombo thank you for the detail.. Can you please help me with the link you mentioned ?

[alterx]

@pnsvinodkumar, he's referring to the first comment in this issue: https://github.com/denoland/deno/issues/2473#issue-453631188

[pnsvinodkumar]

@alterx Thank you.. :pray:

[awkj]

API is stabe? 1.0 is hava new release date? I want use it in production.

[lucacasonato]

API is stabe? 1.0 is hava new release date? I want use it in production.

No the API is not yet stable. It still is constantly changing and we still have many issues open that would break API stability. We should not rush a 1.0 release, because that will undoubtedly introduce design decisions we will regret in the future.

[awkj]

API is stabe? 1.0 is hava new release date? I want use it in production.

No the API is not yet stable. It still is constantly changing and we still have many issues open that would break API stability. We should not rush a 1.0 release, because that will undoubtedly introduce design decisions we will regret in the future.

thanks reply, I think it's good decision, good lucky!

[vijiboy]

API is stabe? 1.0 is hava new release date? I want use it in production.

No the API is not yet stable. It still is constantly changing and we still have many issues open that would break API stability. We should not rush a 1.0 release, because that will undoubtedly introduce design decisions we will regret in the future.

Thanks, Can we update the estimated release date for 1.0.

[tchetwin]

Updated first post now reads:

Therefore we are setting the date of May 13, 2020 as the 1.0 release date.

[FredericLatour]

Are you going to release 1.0 without anything for properly handling module versioning and dependencies?.
I get that people here don't like (to keep it polite) current Node module system. However I don't get how letting each on its own will not lead to a mess of hundreds of approaches.
Or maybe I didn't get the goal of Deno that is maybe just aimed at developing and running small utilities and command line scripts.

[nickmccurdy]

Demo appears to be taking Go’s approach, which is to directly refer to dependency names/URLs in imports rather than managing dependency versions at the project/package level

[somombo]

@FredericLatour I gather Deno also takes alot of influence from Golang. Go Modules have only recently reached stable and fully ready for production in go1.14 (See release notes). Go did not rush to get that right before releasing v1 ... and I don't see why Deno has to either. I do think that the current Go Module system would not be a bad thing to try to mimic into deno though (to whatever extent makes sense). But perhaps past v1

Ref: Talk on Go Modules https://youtu.be/6MbIzJmLz6Q

[kitsonk]

@FredericLatour

Are you going to release 1.0 without anything for properly handling module versioning and dependencies?

The intent has always been that the binary it self would make no assumptions about this. It fetches URLs and local resources, and imports can be remapped based on the browser standard import maps. That is all the binary itself ever needs. Other semantics overlaid on that are external to the Deno binary, and would not prevent shipping a 1.0.

[FredericLatour]

And that's why Go Dep (and various tools) were developed (13.2k stars).
And then in 1.11 Go adopted a divergent approach and Go Dep is still being developed as an alternative.

@kitsonk Even though I get what you say, I completely question this decision. Why paying attention to make developers life simpler with tools like fmt, linter, test, etc ... and say well for developing modern apps that scale, you are completely on your own.

How your life would be if Rust didn't have cargo?

[hayd]

What people are using in is versioning in the url:

import { Application } from "https://deno.land/x/[email protected]/mod.ts";
import { decode } from "https://deno.land/[email protected]/strings/decode.ts";
import * as async from "https://cdn.pika.dev/[email protected]/"

I think it's likely there will be some abstraction over this e.g. #3179 (that can be in user-land), and/or (to shill my own project) a manager for updating dependencies (udd).

Please could you create another issue to discuss your suggestions in detail?

[FredericLatour]

@somombo What's the point mimicing Go strategy.
The guys didn't want:

• modules and dependencies management
• generics
  ...
  And in the end they will get all this. Because there is no way to do without that in a modern development context.

I completely understand that Node module has many problems. However leaving just nothing will lead to hundreds of packages/dependencies management systems to solve a real problem.
And that's frustrating because the project is really great.

[lucacasonato]

@FredericLatour Can we move this discussion to Discord or a separate issue?

[FredericLatour]

@lucacasonato Yes sure ... I will create a separate issue. Does the following title sounds right?: "Module versioning, dependency management, and more ..."

[kitsonk]

How your life would be if Rust didn't have cargo?

Cargo is external to the Rust compiler.

I will create a separate issue. Does the following title sounds right?: "Module versioning, dependency management, and more ..."

There are already issues to this effect. Please add to those.

[FredericLatour]

@kitsonk

Cargo is external to the Rust compiler.

What do you mean by that? A screen shot from the Rust web site front page

Already created a new issue.

[Soremwar]

@FredericLatour It is external to the compiler, it references that files as libs and then the compiler does...well compilation. It doesn't care where were all that came from

You could have a whole Rust project withou any cargo or TOML, it's just Cargo is the default

[FredericLatour]

@Soremwar Yes and then?
If you are working with a team and using publicly available modules + developing modules shared internally, it will let you manage versioning and dependencies in your project or am I missing something?
Moreover it seems to be orthogonal enough to Rust development that is advertised as a main feature, is documented in the Rust documentation and is part of nearly any Rust examples you can find around.

[Soremwar]

@FredericLatour
So? As I said is a default, they will obviously document it based on it.

However your question is How your life would be if Rust didn't have Cargo? Easy, it wouldn't be different

Some other package manager could take it's place without much hassle. And that's the same with Deno, except in the case of Rust, it's mandatory to have some solution to this problem. Deno don't, since JS resolves this natively

I really don't understand what's your problem with this, when someone wants to create a package manager they can easily integrate it with Deno, it's just the team decided it's not their call to choose or make one

[hayd]

@FredericLatour Can we move this discussion to Discord or a separate issue?

Please can we move this to the issue you created over at #4574 .

[Fenzland]

Will 1.0 contain multi-thread (such as a worker with global Deno)?

[colorhook]

I want to embed Deno in my application existed but can't succeed.
There are some kernel modules or structs are private, like GlobalState, I cannot create a Deno instance manually.
So, supporting this sence is that one of Deno's goals?

[ry]

@colorhook This is a goal, but we haven't put much work into making the deno crate's API useable for third parties. The deno_core crate, rather is the API we expect embedder to use. In any case, we will continue to iterate on these APIs beyond 1.0 - what we're trying to stabilize in 1.0 is the JS API.

Have a look at https://github.com/denoland/deno/tree/master/core/examples

[colorhook]

I have some question for help.

1. If I create a library to implement the Web Canvas API, should I assign some web standard class to the global window object? If I do this, Would be conflict with other third libraries?
2. If I implement a winit or sdl2 plugin, the window render loop will blocking the JavaScript code, Is possible change the window render loop to Rust Future manner?

[ry]

@colorhook Modifying and or sharing the event loop is tricky business. We'd like this to be possible - but I expect it's going to be a non-trivial amount of prep work. Open a dedicated issue for these things if you'd like to discuss further.

[josephrocca]

@ry Any thoughts on this before it's locked-in by v1.0?

https://github.com/denoland/deno/issues/2473#issuecomment-583929817

[axetroy]

I think it is necessary to implement the Third Party Modules namespace before v1.0.0

npm is a lesson

Someone always registers a popular package name and then does not update it after a while

It's easy to mislead developers

When most developers choose a library, they will usually search from https://deno.land/x/, but it is possible that this library has been deprecated

of course, We can delete it from registry.json But this will get BREAKING CHANGES.

In the short term, I do n’t see anything wrong with it. In the long term, it ’s bad.

As you can imagine, In 2025y, the name of a popular library, its latest update is 2020y and it is still on the list at https://deno.land/x/. It may still be in use, but no one has updated it, and you cannot remove it from the list

So my suggestion is:

1. Force all modules to add a namespace
2. Decentralized third-party modules registry ref: https://github.com/denoland/registry/issues/117

[samuelgozi]

I think it is necessary to implement the Third Party Modules namespace before v1.0.0

What is the problem with https://denopkg.com? I think something similar is good enough.
Just redirect to raw git, like: deno.land/x/username/repo@branch(or version tag)/mod.ts

Maybe to keep it "cleaner" we could have a convention to always call the entry point at "src/mod.ts" and have the url be: deno.land/x/username/repo@branch.

I think this should be decided before 1.0 or at least deprecate deno.land/x/ before the release to avoid breaking changes later.

[KluVerKamp]

🎉 🎉

[mfulton26]

I don't follow, one could kill completely and restart. Anyway, agree it's not needed for 1.0.

One could, but that wouldn't be as effective/performant as what we would want to build into Deno, which would invalidate the cache for any changed modules, and potentially only reinsert into the isolate the changed recompiled modules, preserving any running state. That would be hot reloading. Restarting would lose any in memory state of "all" the code, not the code that changed.

Is there an issue tracking implementation of hot reloading as suggested here?

I found denon which is to deno what nodemon is to node but I'm wondering if deno supports (or will support) hot reloading itself to maintain state that doesn't need invalidating, etc.