| Age | Commit message (Collapse) | Author |
|---|
|
No longer needed as standalone binaries use `denort`
|
|
* https://github.com/denoland/deno_core/pull/752
* https://github.com/denoland/deno_core/pull/753
Did benchmarking on this and it's slightly faster (couple ms) or equal
to in performance as main.
Closes #23904
|
|
entrypoints (#23496)
Closes https://github.com/denoland/deno/issues/23036
---------
Co-authored-by: Nathan Whitaker <nathan@deno.com>
|
|
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
|
|
install interactions with lockfile (#23918)
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.
|
|
Both ports for the BSDs include patches to the same effect.
|
|
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>
|
|
|
|
Closes #23036
|
|
Co-authored-by: losfair <zhy20000919@hotmail.com>
|
|
Fixes https://github.com/denoland/deno/issues/23943
|
|
(#23888)
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>
|
|
(#23910)
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");
```
|
|
v8 12.6 w/pointer compression enabled.
Closes https://github.com/denoland/deno/issues/18935
|
|
The result of the call is ignored as it throws even when the directory
does not exist.
Closes #23491
|
|
|
|
Closes #23790
|
|
Ref https://github.com/denoland/deno/issues/5289
|
|
`Deno.FsFile.lock[Sync]()` (#23754)
Related #22230
CC @dyedgreen
|
|
Align to latest release process, add some more instructions.
|
|
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>
|
|
`Deno.FsFile.sync[Sync]()` (#23733)
Closes #22230
|
|
partially fixing https://github.com/denoland/deno/issues/23820
https://github.com/denoland/deno/assets/41257923/0adb5d4e-cfd5-4195-9045-19d1c0a07a43
BTW, it is out of scope on this PR that to process type of `@param` to
be an code block due to it's a bit complicated.
|
|
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.
|
|
These repl tests are still a bit flaky. Let's try this.
https://github.com/denoland/deno/actions/runs/9176525869/job/25232001263
|
|
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>
|
|
|
|
Bumped versions for 1.43.6
Co-authored-by: denobot <33910674+denobot@users.noreply.github.com>
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
|
|
Fixes: https://github.com/denoland/deno/issues/23657
Implements `isUtf8` and `isAscii` as ops.
|
|
We were wrapping the display string in an unnecessary pair of triple
backticks, breaking highlighting
Before:
After:
|
|
(#23826)
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
|
|
|
|
|
|
Revealed https://github.com/denoland/deno/issues/23919
Closes #23914
|
|
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
```
|
|
|
|
The cwd lookup was taking 2% of a flamegraph I was looking at.
|
|
|
|
|
|
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.
|
|
is not "clear" (#23850)
|
|
Closes https://github.com/denoland/deno/issues/23860
|
|
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
|
|
Our `MessagePort` to Node's `MessagePort` conversion logic was missing
the case where a `MessagePort` is sent _inside_ the message. This broke
`tinypool` which is used by `vitest` as it relies on some node specific
methods on `MessagePort`.
Fixes https://github.com/denoland/deno/issues/23854 , Fixes
https://github.com/denoland/deno/pull/23871
|
|
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>
|
|
|
|
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
