"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?

@95th let's move the discussion for fmt to #2490

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

We also need to address this at some point before 1.0

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

@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?

@bartlomieju see #1858

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

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

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

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!

@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?

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

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.

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.

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.

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

I think #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.

#3155 (a minimum typescript and deno version requirement) should also be considered for 1.0.

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.

#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.

@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 .

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

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?

@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

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?

@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.

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

#2473 (comment)

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

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.

🎉 🎉

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.