Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upMajor features necessary for 1.0 #2473
Comments
This comment has been minimized.
This comment has been minimized.
We can follow Rust's example for this. Rust's We can do something like Also, is there any existing issue for this? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
We also need to address this at some point before 1.0 Line 196 in 76329cf |
This comment has been minimized.
This comment has been minimized.
@afinch7 could you explain what's to address with |
This comment has been minimized.
This comment has been minimized.
@ry I'll take this:
Where would the CSS live for that? Where is the website server code within deno? |
This comment has been minimized.
This comment has been minimized.
@bartlomieju see #1858 |
This comment has been minimized.
This comment has been minimized.
@acconrad I have a WIP PR open for that denoland/registry#95 |
This comment has been minimized.
This comment has been minimized.
Support for "http proxy" (for downloading modules) should also be considered for 1.0. See #588. Otherwise deno is hardly usable in enterprise environments. |
This comment has been minimized.
This comment has been minimized.
@geglock Thanks - I will add it to the list. |
This comment was marked as resolved.
This comment was marked as resolved.
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? |
This comment has been minimized.
This comment has been minimized.
I presume that supporting other networks such as deno/js/net.ts line 8:
Thanks! |
This comment has been minimized.
This comment has been minimized.
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.
What do you think? 2.) Do you have any release date for 1.0? |
This comment has been minimized.
This comment has been minimized.
@SerkanSipahi 1.) would be quite a small wrapper around #1826, there's already a couple of issues for it. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
I don't follow, one could kill completely and restart. Anyway, agree it's not needed for 1.0. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
I'm removing fs-events as a blocker for 1.0. It's certainly important but a must-have. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
#3155 (a minimum typescript and deno version requirement) should also be considered for 1.0. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
#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. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@ry currently in node.js v12+ there is experimental This is a separate request than native plugins. |
This comment has been minimized.
This comment has been minimized.
@izelnakri Deno supports web standard |
This comment has been minimized.
This comment has been minimized.
@izelnakri deno already has web workers |
This comment has been minimized.
This comment has been minimized.
@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. |
This comment has been minimized.
This comment has been minimized.
We might want to document |
This comment has been minimized.
This comment has been minimized.
@ry I would move denoland/deno_std#428 to #2927 and we can "tick" #2888 in the list. |
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. #3094denoland/deno_website2#49typescript dependencies are not loaded in parallel
#2626#2994signal handlers #2339
- [ ] fs events #1826TS 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.
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.Other minor bugs that are nevertheless blockers:
#588#2873denoland/deno_std#428#2927