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.

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

1. We must manage more js files not our own development.
2. 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.

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

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?

Discussed in https://github.com/denoland/deno/discussions/8549

The core team has discussed this and reviewed the feedback from the community. Based on that, we are going to move forward with the following:

• The --check flag will be implemented for the appropriate subcommands. This will use the built-in tsc for type checking and use tsc for the emit (except for bundles where we will use swc). We may in the future use swc for the emit here as well. This is basically the current default behaviour of Deno.
• The --no-check flag will be deprecated and issue a warning that it is deprecated. The behaviour will not change from its current for now.
• The default behaviour of the command line will be changed so that the code is not type checked and emitted using swc (this is basically the behaviour of --no-check now).

We will raise the PRs necessary to implement this and tentatively aim to introduce this in 1.13.

Why are you doing this?

The goal of the Deno CLI is to be a fun and productive scripting language. A user should be able to hack on some code and quickly see the results of their endeavour. The more "hurdles" that are in the way, the less fun and productive the experience becomes. We ❤️ TypeScript, we want people to use TypeScript more and more, but there are two major challenges with that:

• Type checking is relative slow and expensive. We have tried (almost) everything to speed it up (see: #5432) but a relative small program still takes a second or two to type check, while just transpiling the TypeScript with --no-check takes under 100ms.
• Deno terminates if it encounters a type check diagnostic. That is on us. We should have maybe always treated them as warnings and still executed the output anyways, but we didn't. We could of course change that now, but the problem then is the point above. We don't feel there is a huge amount of value to users to just address this point.

While on the surface it might seem like we are "watering" down Deno, we are motivated to make it easier to use Deno. If you are just starting out, maybe not having used TypeScript in strict mode before, or are just trying to hack a few lines of TypeScript and don't have all of your type annotations right, or you have imported a 3rd party library whose globals conflict with another 3rd party library, you have to spend all your time sorting that out to just find out if your code runs. Again, that isn't fun for anyone and certainly isn't productive.

Also, we have tried to put a lot of effort into the language server, and realistically that is where most people type check their code anyways, in their editor, which means to the majority of people type checking is not the default need they have when running on the command line. It is something they need as a final check, maybe in their CI, maybe before they commit, not every time they want to see if the code runs.

So, we acknowledge that in the discussion there wasn't overwhelming broad support for this, but we think we need to do this not for those already using Deno on a daily basis, but for those experimenting with Deno and TypeScript.

Let’s say that I have a library which is published on npm. If that library

1. is written 100% in typescript
2. has no dependencies
3. does not use node.js built-in modules
4. does not use deno.js built-in modules

what is the best way to add support for deno? Is there a good example repository which does this?

Additionally, if I have library which depends only on modules which dual support both node and deno, does this story change?

Related: https://github.com/denoland/deno/issues/2644

New bundler gets into an infinite loop and never completes the bundle.

This used to work on versions <1.5. Unfortunately can't share the code and I don't know how to minimize the testcase...

Running a simple oak server to illustrate deno-react-example using deno 1.0.3 on Ubuntu results in: "error: No such file or directory (os error 2)"

Would anyone know how to debug this? Thanks

Sorry if this has been asked or discussed before. Can't seem to find it.

Can I make sure imported scripts are in Sandbox mode even if my own script isn't.

// I'd like to make sure this imported script doesn't have access to disk or network even though my code is networking import { SomeFeature} from "https://url.com/some-small-library.ts";

• [x] Add as many tests as possible before refactors
• [x] Add types
• [x] Writable and Readable both have references to children classes (Transform, Duplex, etc) god knows why. Refactor where possible and move code to correspoding child implementations
• [x] Convert errors to class type

Previously Deno cached HTTP resources in a directory structure that was similar to the URL

It looked like this

$DENO_DIR/deps/https/deno.land/std/examples/curl.ts

This was a very simple and nice system as it's very obvious how URLs map to the cache. VS code plugin made assumptions about this layout.

However we discovered there are some URLs that don't easily map to this structure - in particular URLs with query strings, or URLs that don't have a file extension but serve TS/JS. (See #4030)

So now we use a cache structure which is flat and hashes URL

$DENO_DIR/deps/https/deno.land/11d2ae31f7817c87b53893788205d431da511568dcd7bb9c363c6e52fb21a7fd

The VS Code plugin is very important - so let's figure out how to resolve this problem.

cc @axetroy @bartlomieju

This commit does not affect behavior. Just adds some syntactic sugar

Unless someone specifically runs deno run --allow-net deno_http_flash.js "" , which I don't think the current implementation was accounting for

The purpose of --filter is to focus on only a few tests. This is way too much noise:

> deno test -A --filter "streaming api errors while streaming"
Check file:///V:/dax/mod.test.ts
Check file:///V:/dax/src/commands/args.test.ts
Check file:///V:/dax/src/commands/mkdir.test.ts
Check file:///V:/dax/src/commands/pwd.test.ts
Check file:///V:/dax/src/commands/rm.test.ts
Check file:///V:/dax/src/commands/test.ts
Check file:///V:/dax/src/common.test.ts
Check file:///V:/dax/src/console/confirm.test.ts
Check file:///V:/dax/src/console/multiSelect.test.ts
Check file:///V:/dax/src/console/progress/format.test.ts
Check file:///V:/dax/src/console/progress/mod.test.ts
Check file:///V:/dax/src/console/prompt.test.ts
Check file:///V:/dax/src/console/select.test.ts
Check file:///V:/dax/src/deps.test.ts
Check file:///V:/dax/src/pipes.test.ts
Check file:///V:/dax/src/request.test.ts
running 1 test from ./mod.test.ts
streaming api errors while streaming ...
Uncaught error from ./mod.test.ts FAILED
should get stdout when piped ... cancelled (0ms)
should escape arguments ... cancelled (0ms)
should not get stdout when inherited (default) ... cancelled (0ms)
should not get stdout when null ... cancelled (0ms)
should capture stdout when piped ... cancelled (0ms)
should capture stdout when inherited and piped ... cancelled (0ms)
should not get stderr when inherited only (default) ... cancelled (0ms)
should not get stderr when null ... cancelled (0ms)
should capture stderr when piped ... cancelled (0ms)
should capture stderr when inherited and piped ... cancelled (0ms)
should get combined stdout and stderr when specified ... cancelled (0ms)
should not get combined stdout and stderr when not calling combined output ... cancelled (0ms)
should error setting stdout after getting combined output ... cancelled (0ms)
should throw when exit code is non-zero ... cancelled (0ms)
should change the cwd, but only in the shell ... cancelled (0ms)
allow setting env ... cancelled (0ms)
allow setting multiple env ... cancelled (0ms)
set var for command ... cancelled (0ms)
variable substitution ... cancelled (0ms)
stdoutJson ... cancelled (0ms)
CommandBuilder#json() ... cancelled (0ms)
stderrJson ... cancelled (0ms)
should handle interpolation ... cancelled (0ms)
should handle interpolation beside args ... cancelled (0ms)
should handle providing array of arguments ... cancelled (0ms)
raw should handle providing array of arguments ... cancelled (0ms)
raw should handle text provided ... cancelled (0ms)
raw should handle command result ... cancelled (0ms)
command builder should build ... cancelled (0ms)
build with extras ... cancelled (0ms)
build with extras overriding the defaults ... cancelled (0ms)
should handle boolean list 'or' ... cancelled (0ms)
should handle boolean list 'and' ... cancelled (0ms)
should support custom command handlers ... cancelled (0ms)
should not allow invalid command names ... cancelled (0ms)
should unregister commands ... cancelled (0ms)
sleep command ... cancelled (0ms)
test command ... cancelled (0ms)
exit command ... cancelled (0ms)
should provide result from one command to another ... cancelled (0ms)
should actually change the environment when using .exportEnv() ... cancelled (0ms)
exporting env should modify real environment when something changed via the api ... cancelled (0ms)
cwd should be resolved based on cwd at time of method call and not execution ... cancelled (0ms)
should handle the PWD variable ... cancelled (0ms)
timeout ... cancelled (0ms)
piping to stdin ... cancelled (0ms)
streaming api not piped ... cancelled (0ms)
streaming api then non-streaming should error ... cancelled (0ms)
streaming api ... cancelled (0ms)
streaming api errors while streaming ... cancelled (0ms)
command args ... cancelled (0ms)
command .lines() ... cancelled (0ms)
shebang support ... cancelled (0ms)
basic logging test to ensure no errors ... cancelled (0ms)
setting logging ... cancelled (0ms)
printCommand ... cancelled (0ms)
environment should be evaluated at command execution ... cancelled (0ms)
test remove ... cancelled (0ms)
test mkdir ... cancelled (0ms)
copy test ... cancelled (0ms)
move test ... cancelled (0ms)
pwd: pwd ... cancelled (0ms)
progress ... cancelled (0ms)
$.commandExists ... cancelled (0ms)
$.commandExistsSync ... cancelled (0ms)
$.stripAnsi ... cancelled (0ms)
$.dedent ... cancelled (0ms)
running 0 tests from ./src/commands/args.test.ts
running 0 tests from ./src/commands/mkdir.test.ts
running 0 tests from ./src/commands/pwd.test.ts
running 0 tests from ./src/commands/rm.test.ts
running 0 tests from ./src/commands/test.ts
running 0 tests from ./src/common.test.ts
running 0 tests from ./src/console/confirm.test.ts
running 0 tests from ./src/console/multiSelect.test.ts
running 0 tests from ./src/console/progress/format.test.ts
running 0 tests from ./src/console/progress/mod.test.ts
running 0 tests from ./src/console/prompt.test.ts
running 0 tests from ./src/console/select.test.ts
running 0 tests from ./src/deps.test.ts
running 0 tests from ./src/pipes.test.ts
running 0 tests from ./src/request.test.ts

 ERRORS 

./mod.test.ts (uncaught error)
error: (in promise) Error: Exited with code: 1
          throw new Error(`Exited with code: ${code}`);
                ^
    at CommandChild.pipedStdoutBuffer (file:///V:/dax/src/command.ts:545:17)
This error was not caught from a test and caused the test runner to fail on the referenced module.
It most likely originated from a dangling promise, event/timeout handler or top-level code.

 FAILURES

./mod.test.ts (uncaught error)

FAILED | 0 passed | 68 failed | 90 filtered out (816ms)

error: Test failed

At the minimum, we should remove all those "cancelled" test outputs and maybe only say how many tests were ignored in a file with matches. For files with zero matches, we could maybe have some progress message output that gets overwritten and finalizes saying how many files were ignored.

Specifying a file isn't required to run deno test. It will run all the tests in the directory I'm running the command in.

$ deno test -A
Check file:///home/kyle/Projects/deno/react_app/env_test.ts
running 10 tests from ./env_test.ts
...

I found that if I add the --watch flag, it wasn't finding any of the files.

$ deno test --watch -A
Watcher Test started.

ok | 0 passed | 0 failed (0ms)

Watcher Test finished. Restarting on file change...

I found that if I add a path like ., it is able to find the test files like it can without the --watch flag.

$ deno test --watch -A .
Watcher Test started.
running 10 tests from ./env_test.ts
...

I believe that the test command should be able to find the test files without a path when using the --watch flag, like it can without the --watch flag.