This commit adds initial support for ".npmrc" files.
Currently we only discover ".npmrc" files next to "package.json" files
and discovering these files in user home dir is left for a follow up.
This pass supports "_authToken" and "_auth" configuration
for providing authentication.
LSP support has been left for a follow up PR.
Towards https://github.com/denoland/deno/issues/16105
Fixes #23571.
Previously, we required a `deno.json` to be present (or the `--lock`
flag) in order for us to resolve a `deno.lock` file. This meant that if
you were using deno in an npm-first project deno wouldn't use a
lockfile.
Additionally, while I was fixing that, I discovered there were a couple
bugs keeping the future `install` command from using a lockfile.
With this PR, `install` will actually resolve the lockfile (or create
one if not present), and update it if it's not up-to-date. This also
speeds up `deno install`, as we can use the lockfile to skip work during
npm resolution.
The flag lets us exit from read loop without throwing an error when
the stream is cancelled.
This fixes gRPC cancellation example.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This PR removes the use of the custom `utc_now` function in favor of the
`chrono` implementation. It resolves #22864.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
If `@@asyncIterator` is `null` or `undefined`, it should ignores and
fallback to `@@iterator`.
Tests have been merged into WPT.
https://github.com/web-platform-tests/wpt/pull/46374
The proposal of `ReadableStream.from` uses TC39 [GetIterator][] and
[GetMethod][] within it.
GetMethod treats null as undefined.
So if `@@asyncIterator` is `null` it should be ignored and fallback to
`@@iterator`.
[GetIterator]: https://tc39.es/ecma262/#sec-getiterator
[GetMethod]: https://tc39.es/ecma262/#sec-getmethod
```bash
> deno eval "ReadableStream.from({ [Symbol.asyncIterator]: null, [Symbol.iterator]: () => ({ next: () => ({ done: true }) }) }).pipeTo(new WritableStream())"
error: Uncaught (in promise) TypeError: obj[SymbolAsyncIterator] is not a function
ReadableStream.from({ [Symbol.asyncIterator]: null, [Symbol.iterator]: () => ({ next: () => ({ done: true }) }) }).pipeTo(new WritableStream())
^
at getIterator (ext:deno_web/06_streams.js:5105:38)
at Function.from (ext:deno_web/06_streams.js:5207:22)
at file:///D:/work/js/deno/tests/wpt/suite/$deno$eval:1:16
```
---------
Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
While investigating poor cold start performance on my GCP VM (32 cores,
130GB SSD), I found that writing to the various sqlite databases in
DENO_DIR was quite slow. The slowness seems to primarily be caused by
excessive latency from a number of `fsync()` calls.
The performance difference is best demonstrated by deleting the sqlite
databases from DENO_DIR while leaving the downloaded sources in place.
The benchmark (see notes below):
```
piscisaureus@bert-us:~/erofs/source$ export DENO_DIR=./.deno
piscisaureus@bert-us:~/erofs/source$ hyperfine --warmup 3 \
--prepare "rm -rf .deno/*_v1*" \
"deno run -A --cached-only demo.ts" \
"eatmydata deno run -A --cached-only demo.ts" \
"~/deno/target/release/deno run -A --cached-only demo.ts"
Benchmark 1: deno run -A --cached-only demo.ts
Time (mean ± σ): 1.174 s ± 0.037 s [User: 0.153 s, System: 0.184 s]
Range (min … max): 1.104 s … 1.212 s 10 runs
Benchmark 2: eatmydata deno run -A --cached-only demo.ts
Time (mean ± σ): 265.5 ms ± 3.6 ms [User: 138.5 ms, System: 135.1 ms]
Range (min … max): 260.6 ms … 271.2 ms 11 runs
Benchmark 3: ~/deno/target/release/deno run -A --cached-only demo.ts
Time (mean ± σ): 226.2 ms ± 9.2 ms [User: 136.7 ms, System: 93.3 ms]
Range (min … max): 218.8 ms … 247.1 ms 13 runs
Summary
~/deno/target/release/deno run -A --cached-only demo.ts ran
1.17 ± 0.05 times faster than eatmydata deno run -A --cached-only demo.ts
5.19 ± 0.27 times faster than deno run -A --cached-only demo.ts
```
Notes:
* Benchmark 1: unmodified Deno 1.43.6
* Benchmark 2: unmodified Deno 1.43.6 wrapped with `eatmydata` (which is
a tool to neuter `fsync()` calls)
* Benchmark 3: this PR applied on top of Deno 1.43.6
The script that got benchmarked:
```typescript
// demo.ts
import * as express from "npm:express@4.16.3";
import * as postgres from "https://deno.land/x/postgres/mod.ts";
let _dummy = [express, postgres]; // Force use of imports.
console.log("hello world");
```
This is a primordialization effort to improve resistance against users
tampering with the global `Object` prototype.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Currently `task::task_npx_non_existent` is consistently failing in CI
([example](https://github.com/denoland/deno/actions/runs/9192958846/job/25282900321#step:43:2772))
due to the output changing slightly
```
-- OUTPUT START --
Task non-existent npx this-command-should-not-exist-for-you
npm ERR! code E404
npm ERR! 404 Not Found - GET http://localhost:4260/this-command-should-not-exist-for-you
npm ERR! 404
npm ERR! 404 'this-command-should-not-exist-for-you@*' is not in this registry.
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.
npm ERR! A complete log of this run can be found in: /Users/runner/.npm/_logs/2024-05-22T17_58_42_473Z-debug-0.log
-- OUTPUT END --
-- EXPECTED START --
Task non-existent npx this-command-should-not-exist-for-you
npm error code E404
npm error 404 Not Found - GET http://localhost:4260/this-command-should-not-exist-for-you
[WILDCARD]
-- EXPECTED END --
```
I'm not sure what changed in CI to cause this (and I can't repro it
locally, even matching the version of npm and node on the github
runners), but fix it with more lenient expected output for that test.
By default, uses a 60 second timeout, backing off 2x each time (can be
overridden using the hidden `DENO_SLOW_TEST_TIMEOUT` which we implement
only really for spec testing.
```
Deno.test(async function test() {
await new Promise(r => setTimeout(r, 130_000));
});
```
```
$ target/debug/deno test /tmp/test_slow.ts
Check file:///tmp/test_slow.ts
running 1 test from ../../../../../../tmp/test_slow.ts
test ...'test' is running very slowly (1m0s)
'test' is running very slowly (2m0s)
ok (2m10s)
ok | 1 passed | 0 failed (2m10s)
```
---------
Signed-off-by: Matt Mastracci <matthew@mastracci.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This brings in [`runtimelib`](https://github.com/runtimed/runtimed) to
use:
## Fully typed structs for Jupyter Messages
```rust
let msg = connection.read().await?;
self
.send_iopub(
runtimelib::Status::busy().as_child_of(msg),
)
.await?;
```
## Jupyter paths
Jupyter paths are implemented in Rust, allowing the Deno kernel to be
installed completely via Deno without a requirement on Python or
Jupyter. Deno users will be able to install and use the kernel with just
VS Code or other editors that support Jupyter.
```rust
pub fn status() -> Result<(), AnyError> {
let user_data_dir = user_data_dir()?;
let kernel_spec_dir_path = user_data_dir.join("kernels").join("deno");
let kernel_spec_path = kernel_spec_dir_path.join("kernel.json");
if kernel_spec_path.exists() {
log::info!("✅ Deno kernel already installed");
Ok(())
} else {
log::warn!("ℹ️ Deno kernel is not yet installed, run `deno jupyter --install` to set it up");
Ok(())
}
}
```
Closes https://github.com/denoland/deno/issues/21619
Because the buffers are `MaybeUninit<V8Slice<u8>`, and the owner of the
`BoundedBufferChannel` is not obligated to read each and every bit of
data, we may find that some buffers were not automatically dropped if
unread by the time the `BoundedBufferChannelInner` is dropped.
Possible repro:
```
Deno.serve(() => new Response(new ReadableStream({ start(controller) { controller.enqueue(new Uint8Array(100_000_000)) } })));
```
```bash
while true; do curl localhost:8000 | dd count=1; done
```
https://github.com/denoland/deno/pull/23838 might accidentally disable
import assertions support because of V8 12.6 unshipping it, but we want
import assertions to be supported until Deno 2.
This stubs `findSourceMap` in `node:module` by always returning
`undefined` as if it never found a source map. This unblocks the `ava`
test runner.
Fixes https://github.com/denoland/deno/issues/18666
Some npm libraries like `signal-exit` rely on the length of the listener
array returned by `process.listeners("SIGNT")` to be correct to
function. We weren't tracking `SIG*` events there, which broke those npm
libraries.
Fixes https://github.com/denoland/deno/issues/22892
the last commit had a regression, where it removed this branch, I
haven't tested the code but I think it should work
---------
Signed-off-by: Bedis Nbiba <bedisnbiba@gmail.com>
