| Age | Commit message (Collapse) | Author |
|---|
|
Moves the communication methods out of the data structs and onto the
`Connection` struct.
|
|
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
There is no need for this conditional code because it's handled by the
`colors` module.
|
|
|
|
By default, `deno serve` will assign port 8000 (like `Deno.serve`).
Users may choose a different port using `--port`.
`deno serve /tmp/file.ts`
`server.ts`:
```ts
export default {
fetch(req) {
return new Response("hello world!\n");
},
};
```
|
|
Files that were gitignored only were not included in the diagnostic.
|
|
Fixes #23456.
|
|
npm binary commands like `vite` from a `node_modules/.bin` folder will
now execute when defined in a deno.json
Closes https://github.com/denoland/deno/issues/23477
|
|
|
|
|
|
(#23439)
|
|
|
|
This PR enables V8 code cache for ES modules and for `require` scripts
through `op_eval_context`. Code cache artifacts are transparently stored
and fetched using sqlite db and are passed to V8. `--no-code-cache` can
be used to disable.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
If a worker tried to flush large amounts of data right as the test was
ending, it could cause the flush sync marker to get lost.
|
|
`TestEventSender` should not be Clone so we don't end up with multiple
copies of the same writer FD. This is probably not the cause of the test
channel lockups, but it's a lot easier to reason about.
|
|
(#23382)
Closes https://github.com/denoland/deno/issues/23342
Closes https://github.com/denoland/deno/issues/21757
|
|
Due to a terminating NUL that was placed in a `r#` string, we were not
actually NUL-terminating pipe names on Windows. While this has no
security implications due to the random nature of the prefix, it would
occasionally cause random failures when the trailing garbage would make
the pipe name invalid.
|
|
This commit moves logic of dispatching lifecycle events (
"load", "beforeunload", "unload") to be triggered from Rust.
Before that we were executing scripts from Rust, but now we
are storing references to functions from "99_main.js" and calling
them directly.
Prerequisite for https://github.com/denoland/deno/issues/23342
|
|
directory (#23173)
|
|
Had to revert back swc due to
https://github.com/swc-project/swc/issues/8840
Fixes:
- https://github.com/denoland/deno_lint/pull/1262
- https://github.com/denoland/deno_doc/pull/538
- https://github.com/denoland/deno_doc/pull/537
- https://github.com/denoland/deno_graph/pull/430
- https://github.com/denoland/deno_graph/pull/425
- https://github.com/denoland/deno_graph/pull/432
|
|
update to Rust 1.77.2
---------
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
|
|
This is PR a smaller retry of #23066 that simply ensures all async
`ext/fs` ops are accounted for if left hanging in tests. This also sorts
the `OP_DETAILS` in alphabetical order for easy future reading.
When reviewing, it might be best to look at the commits in order for
better understanding.
|
|
Makes the `"nodeModulesDir"` setting take precedence over byonm when
using `DENO_FUTURE`.
|
|
The tests would deadlock if we tried to write the sync marker into a
pipe that was full because one test streamed just enough data to fill
the pipe, so when we went to actually write the sync marker we blocked
when nobody was reading.
We use a two-phase lock for sync markers now: one to indicate "ready to
sync" and the second to indicate that the sync bytes have been received.
|
|
This commit adds enum to "InstallFlags" and "UninstallFlags" that will
allow to support both local and global (un)installation.
Currently the local variant is not used.
Towards https://github.com/denoland/deno/issues/23062
|
|
(#23119)
Unused locals and parameters don't make sense to surface in remote
modules. Additionally, fast check can cause these kind of diagnostics
when publishing, so they should be ignored.
Closes #22959
|
|
|
|
In preparation for upcoming changes to `deno install` in Deno 2.
If `-g` or `--global` flag is not provided a warning will be emitted:
```
⚠️ `deno install` behavior will change in Deno 2. To preserve the current behavior use `-g` or `--global` flag.
```
The same will happen for `deno uninstall` - unless `-g`/`--global` flag
is provided
a warning will be emitted.
Towards https://github.com/denoland/deno/issues/23062
---------
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
|
|
Closes #22786.
TLDR;
```jsonc
{
"tasks": {
// Some comment
//
// describing what the task does
"dev": "deno run -A --watch main.ts"
}
}
```
```bash
deno task
```
|
|
This is slightly breaking as some users want the `vendor` folder
excluded and may not have that specified in their deno.json.
Closes #22833
|
|
This commit changes "deno init" subcommand to use "jsr:" specifier for
standard library "assert" module. It is unversioned, but we will change
it to `@^1` once `@std/assert` release version 1.0.
This allows us to start decoupling `deno` and `deno_std` release. The
release scripts have been updated to take that into account.
|
|
Adds cross-platform shebang support (supports using shebangs in `deno
task` on Windows)
https://github.com/denoland/deno_task_shell/pull/113
|
|
This commit changes `deno add` to always produce a multiline config
file.
In v1.41.3:
```
$ mkdir foo
$ cd foo
$ deno add @std/assert
Created deno.json configuration file.
Add @std/assert - jsr:@std/assert@^0.220.0
$ cat deno.json
{ "imports": { "@std/assert": "jsr:@std/assert@^0.220.0" } }
```
Now:
```
$ mkdir foo
$ cd foo
$ deno add @std/assert
Created deno.json configuration file.
Add @std/assert - jsr:@std/assert@^0.220.0
$ cat deno.json
{
"imports": {
"@std/assert": "jsr:@std/assert@^0.220.0"
}
}
```
|
|
Fixes https://github.com/denoland/deno/issues/20847
Co-authored-by: Nathan Whitaker <nathan@deno.com>
|
|
benchmark (#23083)
Fixes #23053.
Two small bugs here:
- the existing condition for printing out the group header was broken.
it worked in the reproducer (in the issue above) without filtering only
by accident, due to setting `self.has_ungrouped = true` once we see the
warmup bench. Knowing that we sort benchmarks to put ungrouped benches
first, there are only two cases: 1) we are starting the first group 2)
we are ending the previous group and starting a new group
- when you passed `--filter` we were applying that filter to the warmup
bench (which is not visible to users), so we suffered from jit bias if
you were filtering (unless your filter was `<warmup>`)
TLDR;
Running
```bash
deno bench main.js --filter="G"
```
```js
// main.js
Deno.bench({
group: "G1",
name: "G1-A",
fn() {},
});
Deno.bench({
group: "G1",
name: "G1-B",
fn() {},
});
```
Before this PR:
```
benchmark time (avg) iter/s (min … max) p75 p99 p995
--------------------------------------------------------------- -----------------------------
G1-A 303.52 ps/iter3,294,726,102.1 (254.2 ps … 7.8 ns) 287.5 ps 391.7 ps 437.5 ps
G1-B 3.8 ns/iter 263,360,635.9 (2.24 ns … 8.36 ns) 3.84 ns 4.73 ns 4.94 ns
summary
G1-A
12.51x faster than G1-B
```
After this PR:
```
benchmark time (avg) iter/s (min … max) p75 p99 p995
--------------------------------------------------------------- -----------------------------
group G1
G1-A 3.85 ns/iter 259,822,096.0 (2.42 ns … 9.03 ns) 3.83 ns 4.62 ns 4.83 ns
G1-B 3.84 ns/iter 260,458,274.5 (3.55 ns … 7.05 ns) 3.83 ns 4.45 ns 4.7 ns
summary
G1-B
1x faster than G1-A
```
|
|
|
|
Before this PR, we didn't have any integration tests set up for the
`jupyter` subcommand.
This PR adds a basic jupyter client and helpers for writing integration
tests for the jupyter kernel. A lot of the code here is boilerplate,
mainly around the message format for jupyter.
This also adds a few basic integration tests, most notably for
requesting execution of a snippet of code and getting the correct
results.
|
|
This automatically opts packages (deno.json's with a name, version, and
exports field) into the "jsr" lint tag.
|
|
reporter (#22797)
This patch gets JUnit reporter to output more detailed information for
test steps (subtests).
## Issue with previous implementation
In the previous implementation, the test hierarchy was represented using
several XML tags like the following:
- `<testsuites>` corresponds to the entire test (one execution of `deno
test` has exactly one `<testsuites>` tag)
- `<testsuite>` corresponds to one file, such as `main_test.ts`
- `<testcase>` corresponds to one `Deno.test(...)`
- `<property>` corresponds to one `t.step(...)`
This structure describes the test layers but one problem is that
`<property>` tag is used for any use cases so some tools that can ingest
a JUnit XML file might not be able to interpret `<property>` as
subtests.
## How other tools address it
Some of the testing frameworks in the ecosystem address this issue by
fitting subtests into the `<testcase>` layer. For instance, take a look
at the following Go test file:
```go
package main_test
import "testing"
func TestMain(t *testing.T) {
t.Run("child 1", func(t *testing.T) {
// OK
})
t.Run("child 2", func(t *testing.T) {
// Error
t.Fatal("error")
})
}
```
Running [gotestsum], we can get the output like this:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<testsuites tests="3" failures="2" errors="0" time="1.013694">
<testsuite tests="3" failures="2" time="0.510000" name="example/gosumtest" timestamp="2024-03-11T12:26:39+09:00">
<properties>
<property name="go.version" value="go1.22.1 darwin/arm64"></property>
</properties>
<testcase classname="example/gosumtest" name="TestMain/child_2" time="0.000000">
<failure message="Failed" type="">=== RUN TestMain/child_2
 main_test.go:12: error
--- FAIL: TestMain/child_2 (0.00s)
</failure>
</testcase>
<testcase classname="example/gosumtest" name="TestMain" time="0.000000">
<failure message="Failed" type="">=== RUN TestMain
--- FAIL: TestMain (0.00s)
</failure>
</testcase>
<testcase classname="example/gosumtest" name="TestMain/child_1" time="0.000000"></testcase>
</testsuite>
</testsuites>
```
This output shows that nested test cases are squashed into the
`<testcase>` layer by treating them as the same layer as their parent,
`TestMain`. We can still distinguish nested ones by their `name`
attributes that look like `TestMain/<subtest_name>`.
As described in #22795, [vitest] solves the issue in the same way as
[gotestsum].
One downside of this would be that one test failure that happens in a
nested test case will end up being counted multiple times, because not
only the subtest but also its wrapping container(s) are considered to be
failures. In fact, in the [gotestsum] output above, `TestMain/child_2`
failed (which is totally expected) while its parent, `TestMain`, was
also counted as failure. As
https://github.com/denoland/deno/pull/20273#discussion_r1307558757
pointed out, there is a test runner that offers flexibility to prevent
this, but I personally don't think the "duplicate failure count" issue
is a big deal.
## How to fix the issue in this patch
This patch fixes the issue with the same approach as [gotestsum] and
[vitest].
More specifically, nested test cases are put into the `<testcase>` level
and their names are now represented as squashed test names concatenated
by `>` (e.g. `parent 2 > child 1 > grandchild 1`). This change also
allows us to put a detailed error message as `<failure>` tag within the
`<testcase>` tag, which should be handled nicely by third-party tools
supporting JUnit XML.
## Extra fix
Also, file paths embedded into XML outputs are changed from absolute
path to relative path, which is helpful when running the test suites in
several different environments like CI.
Resolves #22795
[gotestsum]: https://github.com/gotestyourself/gotestsum
[vitest]: https://vitest.dev/
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
Closes #22936
|
|
publishing (#22948)
Closes #22657
|
|
Adds a `--fix` option to deno lint. This currently doesn't work for
basically any rules, but we can add them over time to deno lint.
|
|
Fixes #22941.
In that case, the only file with coverage was the `test.ts` file. The
coverage reporter filters out test files before compiling its report, so
after filtering we were left with an empty set of files. Later on it's
assumed that there is at least 1 file to be reported on, and we panic.
Instead of panicking, just issue an error after filtering.
|
|
(#22932)
|
|
|
|
Fixes #22837
|
|
exprs (#22849)
Several fixes in deno_graph:
* https://github.com/denoland/deno_graph/pull/411
* https://github.com/denoland/deno_graph/pull/413
* https://github.com/denoland/deno_graph/pull/414
* https://github.com/denoland/deno_graph/pull/415
* https://github.com/denoland/deno_graph/pull/416
* https://github.com/denoland/deno_graph/pull/417
Also created https://github.com/denoland/publish_smoke_tests to help
prevent regressions in the future.
Closes https://github.com/denoland/deno/issues/22829
Closes https://github.com/denoland/deno/issues/22819
Closes https://github.com/denoland/deno/issues/22802
|
|
|
|
Fixes https://github.com/denoland/deno_std/issues/4473
|
