search

denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
98.19k stars 5.41k forks source link

1.0 #2473

Closed ry closed 4 years ago

ry commented 5 years ago

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.

Do any major API renames.

Other minor bugs that are nevertheless blockers:

95th commented 5 years ago

"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 commented 5 years ago

@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 commented 5 years ago

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

bartlomieju commented 5 years ago

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

acconrad commented 5 years ago

@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 commented 5 years ago

@bartlomieju see #1858

mtharrison commented 5 years ago

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

geglock commented 5 years ago

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 commented 5 years ago

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

nayeemrmn commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

kitsonk commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

andyfleming commented 5 years ago

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 commented 5 years ago

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

andyfleming commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

izelnakri commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@izelnakri deno already has web workers

CGQAQ commented 5 years ago

@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 commented 5 years ago

We might want to document Workers at least in the manual

kitsonk commented 5 years ago

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

lucacasonato commented 4 years ago

@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 commented 4 years ago

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

brandonkal commented 4 years ago

Some other features worth considering for 1.0:

teleclimber commented 4 years ago

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.

Thanks!

awkj commented 4 years ago

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

Aloso commented 4 years ago

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

That's what tslint is for.

awkj commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

maxmellen commented 4 years ago

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

ShawnTalbert commented 4 years ago

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 commented 4 years ago

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.

image

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 commented 4 years ago

@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 commented 4 years ago

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

pnsvinodkumar commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

alterx commented 4 years ago

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

pnsvinodkumar commented 4 years ago

@alterx Thank you.. :pray:

awkj commented 4 years ago

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