A secure JavaScript and TypeScript runtime

deno A JavaScript runtime using V8 6.8 and Go. Supports TypeScript 2.8 out of the box. No package.json, no npm. Not backwards compatible with Node. Imports reference source code URLs only. import { test }

README
Issues 626

Popular

Deno

A secure runtime for JavaScript and TypeScript.

Deno aims to provide a productive and secure scripting environment for the modern programmer. It is built on top of V8, Rust, and TypeScript.

Please read the introduction for more specifics.

求不要更新了，老子学不动了

opened May 31, 2018 by fujiazhang 513

Closed

"deno compile" into executable

I was wondering if there's any plan to support compiling deno scripts into a single executable?

I saw "Single executable" as a feature, but the code that follows seems to suggest it's deno as the single executable, not the programs executed with it.

It'd be awesome to support something like go build main.go or something like zeit/pkg.

cli feat

opened Oct 13, 2018 by matthewmueller 111

Closed

Maybe need a package management tool

Import from url is very hard to use. I think is not a good idea. If so,

We must manage more js files not our own development.
Heavily dependent on the network, because the third package also can import another packages.

Like C#\Java, the nuget and maven is good for use. Maybe use that mode can help us manage the packages.

opened May 31, 2018 by hstarorg 94

Closed

1.0

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.

[x] replace libdeno with rusty_v8 https://github.com/denoland/deno/issues/3530
[x] "deno --debug" https://github.com/denoland/deno/issues/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). https://github.com/denoland/deno/pull/4484
[x] 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 https://github.com/denoland/deno/issues/2390~~, ~~double downloads happen https://github.com/denoland/deno/issues/2442~~, the cache needs to be refactored https://github.com/denoland/deno/issues/2057.
[X] 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 https://github.com/denoland/deno/pull/2360.
[x] Dynamic import. 50% complete at the time of writing. https://github.com/denoland/deno/issues/1789
[x] "deno test" test runner https://github.com/denoland/deno_std/issues/193
[x] "deno fmt" is slow on the first run. It download a couple of large prettier bundles. https://github.com/denoland/deno/issues/2490
[x] We need to support d.ts files https://github.com/denoland/deno/issues/1432
[X] "deno bundle" outputs a single AMD bundle of your program. This is useful to share code with websites. Early work has started: https://github.com/denoland/deno/pull/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. https://github.com/denoland/deno/issues/986~~ Not for 1.0
[x] "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. https://github.com/denoland/deno_std/issues/471
[x] 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 https://github.com/denoland/deno/pull/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. https://github.com/denoland/deno/pull/3372
[x] Support TLS https://github.com/denoland/deno/issues/3009
[ ] The web-server should be faster.
[X] 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 https://github.com/denoland/registry/commit/b78e6ae331004859aad7b01ed452f6b00265b035
[X] ~~If you use "docs.deno.land" you will get auto-generated docs. https://github.com/denoland/deno/issues/3094~~ https://github.com/denoland/deno_website2/pull/49
[x] typescript dependencies are not loaded in parallel ~~#2626~~ https://github.com/denoland/deno/issues/2994
[x] signal handlers https://github.com/denoland/deno/issues/2339 #3757
[X] fs events https://github.com/denoland/deno/issues/1826 #3452
[ ] TS and source maps are correctly recompiled https://github.com/denoland/deno/issues/2945
[x] Remove tokio_util::block_on https://github.com/denoland/deno/issues/2960
[x] "deno test" is slow (when running on std) https://github.com/denoland/deno/issues/2789
[x] deno lock file https://github.com/denoland/deno/issues/200

Do any major API renames.

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

Other minor bugs that are nevertheless blockers:

[x] async iteration on fetch bodies https://github.com/denoland/deno/issues/2520
[x] https://github.com/denoland/deno_std/issues/442
[x] support onload https://github.com/denoland/deno/issues/2386
[x] support proxy for module downloads ~~https://github.com/denoland/deno/issues/588~~ https://github.com/denoland/deno/issues/2873
[x] panic on too many open files https://github.com/denoland/deno/issues/2243
[x] we need a way to use typescript compiler from userland ~~https://github.com/denoland/deno_std/issues/428~~ #2927
[x] 'url' variable can't be used https://github.com/denoland/deno/issues/2888
[x] https://github.com/denoland/deno/issues/3367
[x] https://github.com/denoland/deno/issues/3852 Can't import jspm modules
[x] #3401 Permissionless static relative imports are dangerous

opened Jun 7, 2019 by ry 79

Closed

import with absolute path?

Okay, this project looks really interesting so far. While watching the talk I just noticed one thing that might be a problem for some developers. That's just allowing imports with relative path's (besides URLs). There are a lot of questions on the internet on how one can import a file in TS/Webpack/whatever relative to the project root. With relative paths people will end up with things like import { foo } from '../../../../modules/featureA/foo.ts'. Or was it just ../../../modules/...? What if I move my files around? Yes, you have to update your imports anyway. But figuring out how many directories you have to go up is a very tedious task on its own.

In the talk, you/Ryan talked about browser compatibility. I haven't tried out ES modules in the browser just yet. But I'm pretty sure it also supports absolute paths. Absolute in that context means relative to the web root. It would be really handy if we were able to just write import { foo } from '/modules/featureA/foo.ts'.

Of course, now there's the question: What is the root directory of a deno application? The only thing that makes sense to me right now is the folder that contains the entry file ‒ basically what process.cwd() is in node. But I also think it's fine to place the entry file in the most top-level directory of the project, isn't it?

Or is there any problem about absolute paths I didn't think about so far? What do you think about that?

opened Jun 7, 2018 by alinnert 71

Closed

Wanted: serverless deno configuration

Would like some scripts and documentation on how to deploy to AWS Lambda, Serverless, GCloud functions, Azure Functions, etc.

stale

opened Jan 3, 2019 by ry 60

Open

chore: format toml files internally

This change adds using dprint-plugin-toml to format toml files internally.

opened Jul 31, 2021 by dsherret 0

Open

Slow message passing between main and worker (4x slower than Node)

For a basic ping-pong like sending and receiving in succession 100_000 messages, Node is taking 1s and Deno is taking 4s for me. I was not expecting that much difference. Here is basically the content of worker.mjs:

// deno_worker.mjs
self.onmessage = (msg) => {
  self.postMessage(msg.data);
};

And here is the content of main.mjs:

// deno_main.mjs
let msgCount = 100000;
console.log("Sending", msgCount, " messages ...");

let worker = new Worker(new URL("./deno_worker.mjs", import.meta.url).href, {
  type: "module",
});

worker.onmessage = (msg) => {
  if (msg.data >= msgCount) {
    worker.terminate();
    Deno.exit();
  } else {
    worker.postMessage(msg.data + 1);
  }
};

worker.postMessage(0);

You can find in that gist the exact files I'm using. I'm running the deno code and the node code with respectively:

time deno run --allow-read deno_main.mjs
time node node_main.mjs

My system:

archlinux, kernel 5.13.4
node v14.15.5
deno 1.12.1

opened Jul 31, 2021 by mpizenberg 4

Open

Make DENO_COVERAGE_DIR public

The DENO_UNSTABLE_COVERAGE_DIR is the environment variable that actually controls if coverage collection takes place or not. It has a terrible name and is not documented anywhere as it is not considered public at the moment.

Using an environment variable is the most common way to determine if coverage should be collected and where it should be collected too.

This implies that we remove deno test --coverage which was kept for backwards compatibility in 1.x. The removal of the coverage flag would probably have to be a 2.0 change.

Usage would be:

export DENO_COVERAGE_DIR="some/path"
deno run ...
deno test ...
deno test ...
deno coverage --lcov > cov.lcov

opened Jul 31, 2021 by caspervonb 0

Open

feat(extensions/fetch): Add Origin header to outgoing requests for fetch

fix https://github.com/denoland/deno/issues/10992

opened Jul 30, 2021 by F3n67u 0

Open

feat(lsp): Implement refactoring

Related https://github.com/denoland/vscode_deno/issues/433

opened Jul 30, 2021 by jeanp413 0

Open

[Suggestion] Allow configuring spaces in `deno fmt`

I understand that this has been brought up(as formatter options, but i think it would include this) before, but please read what I have to say as I believe I have newer and more solid reasoning for this change.

Since a meta/config file(#3179) is on the Q3 2021 Roadmap and Q3 is coming soon, I'd like to bring up adding space amount customizations:

I've decided to bring this up as an issue instead of in #3179 itself because #3179 in particular seems to be targeted at putting current configuration options into a file, and the discussion in that issue seems to have mostly went to a config file format.

The reason I am bringing this up in the first place is that I don't use deno fmt because I am unable to make it format my code with 4 spaces, I will be focusing on that:

Reasoning

It doesn't make any sense to not allow customizations for such a simple option that has no reason for being as they are in the current settings, the defaults can still be whatever it is now, but it wouldn't hurt anyone to have an option for 4 spaces that, in my experience. doesn't even impact readability.
It is not some obscure formatting option that is only used by a few people(like having semicolons after a functions closing bracket), it is a formatting option that a lot of people want, like, and want to be able to use with deno fmt
This wouldn't really change a lot(if anything) in terms of consistency, most people will still use the default, if someone wants to use 4 spaces they will either: 1. Adapt to 2 spaces because they don't have the option; or 2. Use 4 spaces anyway with some other formatter(I've seen projects like this) or manually(me); Not having this option makes people's lives harder(having to adapt to 2 spaces or use a different tool) at no real benefit since there's always going to be projects with 2 spaces and 4 spaces.
A few people have brought up the option of using Prettier, dprint by itself, or writing my own formatter, I do not want to do that personally and I wouldn't really expect someone if they were working on a project of mine to install prettier or dprint or my own formatter. I understand that the "adapt or go" philosophy(which is whats happening here) is not wanted in the Deno community, and as such, it should not be wanted in the toolchain either, especially as it is a simple change that is wanted by many.
Some have brought up the argument that it wastes company time and money to decide on formatting options, I do not think this holds up, because it is 1 simple option and as such would not take very long to decide on.
I do not believe that making this change would force the core team to include small things as an option in deno fmt, because most things in deno fmt are reasonable and have a good reason for them being as they are. If this is wanted and eventually merged, it will be up to core and others to decide if similar options shall get in. Although I do not believe making these kind of decisions will be necessary because there are not many other things that have no reason to be as they are.
Deno is supposed to be a one-stop shop for all JavaScript needs this, alienizing people like this is not a good way to achieve that goal and make people use Deno as the one-stop shop for their JS needs, this also feeds into my earlier reasoning regarding using prettier or dprint.

Prior Art

I understand that Deno likes following other projects such as Rust or Go in it's decisions, so I will be listing a few formatters that allow this option, or has other changes that fixes this problem:
- gofmt: Formats using tabs, this fixes this problem and also allows for better accesibility
- rustfmt: Has 4 spaces by default, allows changing this amount in rustfmt.toml file
- Prettier: Allows changing spaces in a .prettierc file

Development/Meeting Time

A few people on discord have brought up the topic of (core's) wasting development and/or meeting time on such simple and opinionated things:

I am willing to implement this myself, if that is what is needed, and if a PR implementing that will get accepted.
A meta/config file is already going to be discussed due to #3179 being on the Q3 Roadmap, and it is a simple addition to that, so I do not think it will take long to discuss.

Discord

I have created a thread on discord in the #dev-fmt channel where there was some discussion related to this:

https://discord.com/channels/684898665143206084/870438916136771614/870438917860651028

opened Jul 29, 2021 by grian32 0

Information

Category: JavaScript / Miscellaneous
Watchers: 1.7k
Star: 76.9k
Fork: 4.1k
Last update: Aug 1, 2021

Resource links

https://github.com/denoland/deno

Share this repo

Related Repos

Miscellaneous

113

Priority Queue on Ethereum

Eth-Heap What? A Binary Heap data structure is the simplest implementation of a Priority Queue (for instance order-books). It "partially sorts" data so that the highest priority item can always be found instantly at th

Miscellaneous

157

WebRTC Connect Experiment - https://aquigorka.com/webrtc-qr/

P2P Connect Experiment Using QR codes to share signalling data between two devices a WebRTC connection is established. Open up https://aquigorka.com/webrtc-qr/ in a desktop browser and in a mobile browser. In either browser

Miscellaneous

420

Write JS code that runs in a different context. E.g. use the DOM in a Web Worker.

Via.js: use the DOM in a Web Worker Web Workers have a few APIs, but most web APIs are still only available in the main thread. This makes it harder to use workers when you need access to features like document, CSS styles, i

Miscellaneous

960

Project management directly from the TODOs in your codebase

Toodles Toodles scrapes your entire repository for TODO entries and organizes them so you can manage your project directly from the code. View, filter, sort, and edit your TODO's with an easy to use web application. When you

Miscellaneous

6.8k

💻 JavaScript implementation of different computer science algorithms.

About This repository contains JavaScript implementations of famous computer science algorithms. API reference with usage examples available here. Development To install all dev dependencies Call: npm install

Miscellaneous

📚 Community-driven set of best practices for AngularJS application development

Introduction The goal of this style guide is to present a set of best practices and style guidelines for one AngularJS application. These best practices are collected from: AngularJS source code Source code or articles I'

Miscellaneous

2.4k

Static analysis for Angular projects.

codelyzer A set of tslint rules for static code analysis of Angular TypeScript projects. (If you are using ESLint check out the new angular-eslint repository.) You can run the static code analyzer over web apps, Nati

Miscellaneous

Light Cache for nodeJs and browserJs with TTL.

Introduction Cache your data with TTL. Using this package in node.js and browser. Installation By npm npm install cache-bucket Or by yarn yarn add cache-bucket Support Node.js FileCache