Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.0 #2473

Closed
40 of 43 tasks
ry opened this issue Jun 7, 2019 · 79 comments · Fixed by #5273
Closed
40 of 43 tasks

1.0 #2473

ry opened this issue Jun 7, 2019 · 79 comments · Fixed by #5273

Comments

@ry
Copy link
Member

@ry ry commented Jun 7, 2019

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.

  • replace libdeno with rusty_v8 #3530

  • "deno --debug" #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). #4484

  • 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 #2390, double downloads happen #2442, the cache needs to be refactored #2057.

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

  • Dynamic import. 50% complete at the time of writing. #1789

  • "deno test" test runner denoland/deno_std#193

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

  • We need to support d.ts files #1432

  • "deno bundle" outputs a single AMD bundle of your program. This is useful to share code with websites. Early work has started: #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. #986 Not for 1.0

  • "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. denoland/deno_std#471

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

  • Support TLS #3009

  • The web-server should be faster.

  • 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 denoland/registry@b78e6ae

  • If you use "docs.deno.land" you will get auto-generated docs. #3094 denoland/dotland#49

  • typescript dependencies are not loaded in parallel #2626 #2994

  • signal handlers #2339 #3757

  • fs events #1826 #3452

  • TS and source maps are correctly recompiled #2945

  • Remove tokio_util::block_on #2960

  • "deno test" is slow (when running on std) #2789

  • deno lock file #200

Do any major API renames.

  • #2384
  • #2474
  • #2635 clean up ErrorKinds
  • #2767 use web standard Permission API
  • #2730 register_op
  • denoland/deno_std#562 test(name, fn)
  • #2123 Deno.args
  • #2934 referencing d.ts files
  • #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.
  • #3520 window.location should be cwd?

Other minor bugs that are nevertheless blockers:

@ry ry pinned this issue Jun 7, 2019
@95th
Copy link
Contributor

@95th 95th commented Jun 10, 2019

"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
Copy link
Member Author

@ry ry commented Jun 10, 2019

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

@afinch7
Copy link
Contributor

@afinch7 afinch7 commented Jun 15, 2019

We also need to address this at some point before 1.0

deno/cli/ops.rs

Line 196 in 76329cf

msg::Any::FetchModuleMetaData => Some(op_fetch_module_meta_data),

@bartlomieju
Copy link
Member

@bartlomieju bartlomieju commented Jun 15, 2019

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

@acconrad
Copy link
Contributor

@acconrad acconrad commented Jun 15, 2019

@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
Copy link
Contributor

@afinch7 afinch7 commented Jun 15, 2019

@mtharrison
Copy link
Contributor

@mtharrison mtharrison commented Jun 15, 2019

@acconrad I have a WIP PR open for that denoland/registry#95

@geglock
Copy link

@geglock geglock commented Jun 25, 2019

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
Copy link
Member Author

@ry ry commented Jun 25, 2019

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

@nayeemrmn

This comment has been minimized.

@teleclimber
Copy link

@teleclimber teleclimber commented Sep 27, 2019

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
Copy link

@SerkanSipahi SerkanSipahi commented Oct 11, 2019

@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
Copy link
Contributor

@hayd hayd commented Oct 11, 2019

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

@kitsonk
Copy link
Contributor

@kitsonk kitsonk commented Oct 11, 2019

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
Copy link
Contributor

@hayd hayd commented Oct 11, 2019

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
Copy link
Contributor

@kitsonk kitsonk commented Oct 11, 2019

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
Copy link
Member Author

@ry ry commented Oct 11, 2019

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

@andyfleming
Copy link
Contributor

@andyfleming andyfleming commented Oct 19, 2019

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.

@andyfleming
Copy link
Contributor

@andyfleming andyfleming commented Oct 19, 2019

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

@andyfleming
Copy link
Contributor

@andyfleming andyfleming commented Oct 19, 2019

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.

@hayd
Copy link
Contributor

@hayd hayd commented Apr 2, 2020

@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
Copy link
Contributor

@Fenzland Fenzland commented Apr 3, 2020

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

@colorhook
Copy link

@colorhook colorhook commented Apr 5, 2020

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
Copy link
Member Author

@ry ry commented Apr 5, 2020

@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

@ry ry changed the title Major features necessary for 1.0 1.0 Apr 16, 2020
@colorhook
Copy link

@colorhook colorhook commented Apr 20, 2020

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
Copy link
Member Author

@ry ry commented Apr 20, 2020

@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
Copy link
Contributor

@josephrocca josephrocca commented May 3, 2020

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

#2473 (comment)

@axetroy
Copy link
Contributor

@axetroy axetroy commented May 4, 2020

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: denoland/registry#117

@samuelgozi
Copy link

@samuelgozi samuelgozi commented May 4, 2020

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
Copy link
Contributor

@KluVerKamp KluVerKamp commented May 13, 2020

🎉 🎉

@mfulton26
Copy link

@mfulton26 mfulton26 commented Jun 27, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.