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

Major features necessary for 1.0 #2473

Open
ry opened this issue Jun 7, 2019 · 28 comments
Open

Major features necessary for 1.0 #2473

ry opened this issue Jun 7, 2019 · 28 comments

Comments

@ry
Copy link
Collaborator

@ry ry commented Jun 7, 2019

Release estimate as of Oct 24, 2019: End of year

We've got a lot of issues, some are tiny, others are big features. I want to outline what I perceive to be the major missing bits before we can consider 1.0

  • "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).

  • 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

  • "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/deno_website2#49

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

  • signal handlers #2339

- [ ] fs events #1826

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

Other minor bugs that are nevertheless blockers:

@ry ry pinned this issue Jun 7, 2019
@95th

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor

@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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor

@afinch7 afinch7 commented Jun 15, 2019

@mtharrison

This comment has been minimized.

Copy link
Contributor

@mtharrison mtharrison commented Jun 15, 2019

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

@geglock

This comment has been minimized.

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

This comment has been minimized.

Copy link
Collaborator Author

@ry ry commented Jun 25, 2019

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

@nayeemrmn

This comment was marked as resolved.

Copy link
Contributor

@nayeemrmn nayeemrmn commented Jul 26, 2019

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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.

@kitsonk

This comment has been minimized.

Copy link
Contributor

@kitsonk kitsonk commented Oct 20, 2019

#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

This comment has been minimized.

Copy link
Contributor

@andyfleming andyfleming commented Oct 20, 2019

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

@izelnakri

This comment has been minimized.

Copy link

@izelnakri izelnakri commented Nov 23, 2019

@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

This comment has been minimized.

Copy link
Contributor

@bartlomieju bartlomieju commented Nov 23, 2019

@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

This comment has been minimized.

Copy link
Collaborator Author

@ry ry commented Nov 23, 2019

@izelnakri deno already has web workers

@CGQAQ

This comment has been minimized.

Copy link

@CGQAQ CGQAQ commented Nov 25, 2019

@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

This comment has been minimized.

Copy link
Contributor

@kevinkassimo kevinkassimo commented Nov 25, 2019

We might want to document Workers at least in the manual

@kitsonk

This comment has been minimized.

Copy link
Contributor

@kitsonk kitsonk commented Nov 26, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.