| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
Closes #23079
|
|
|
|
|
|
Closes #22851
|
|
Fork PR: https://github.com/denoland/TypeScript/pull/10
Closes #23080
|
|
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>
|
|
Fixes regression introduced in
https://github.com/denoland/deno/pull/22112 that
removed checks if `Deno.test` or `Deno.bench` are not used in respective
subcommands.
Closes https://github.com/denoland/deno/issues/23041
|
|
This has been incorrect since the function adopted its (more intuitive)
current behavior in 9268df5f3. The same behavior change was backported
to v1.39.3 in 87e954f54.
|
|
Internal refactor that changes how we use ops in `deno bench`
subcommand.
This brings it in line to what we do in `deno test` subcommand.
|
|
Extracted from #22718
|
|
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.
|
|
|
|
Changes the behaviour in Deno to just always load ES modules in npm
packages even if they're defined as CJS.
Closes #22818
|
|
* feat: implement exit status var
(https://github.com/denoland/deno_task_shell/pull/110)
* feat: support input redirects
(https://github.com/denoland/deno_task_shell/pull/106)
* feat: support output fd redirects for stdout and stderr
(https://github.com/denoland/deno_task_shell/pull/111)
* feat: support parsing fd redirects
(https://github.com/denoland/deno_task_shell/pull/107)
* fix: exit error code on arg parse failure
(https://github.com/denoland/deno_task_shell/pull/112)
Closes #22989
|
|
|
|
Just making sure we read this env var once per process.
|
|
|
|
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.
|
|
(#22944)
Closes https://github.com/denoland/deno/issues/22934
|
|
|
|
(#22932)
|
|
|
|
Forward 1.41.3 release commit
Co-authored-by: denobot <33910674+denobot@users.noreply.github.com>
Co-authored-by: nathanwhit <nathanwhit@users.noreply.github.com>
|
|
Fixes #22837
|
|
In addition to the reasons for this outlined by @nayeemrmn in #14877
(which I think are reasons alone to not do this), this simplifies things
a lot because then we don't need to implement the following:
1. Need to handle a JSR module dynamically importing a module within it.
2. Need to handle importing an export of a JSR dep then another export
dynamically loaded later.
Additionally, people should be running `deno check dynamic_import.ts`
instead of relying on this behaviour.
Landing this as a fix because it's blocking people in some scenarios and
the current behaviour is broken (I didn't even have to change any tests
to remove this, which is bad).
Closes #22852
Closes #14877
Closes #22580
|
|
"fully-granted" state (#22894)
Skips the access check if the specific unary permission is in an
all-granted state. Generally prevents an allocation or two.
Hooks up a quiet "all" permission that is automatically inherited. This
permission will be used in the future to indicate that the user wishes
to accept all side-effects of the permissions they explicitly granted.
The "all" permission is an "ambient flag"-style permission that states
whether "allow-all" was passed on the command-line.
|
|
|
|
Co-authored-by: Matt Mastracci <matthew@mastracci.com>
|
|
|
|
Unlocking a potential perf optimization at a later date -- carry the
`allow_all` flag into the permission container.
|
|
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
|
|
Issue https://github.com/denoland/deno/issues/22222
This PR moves `runtime/permissions` code to a upstream crate called
`deno_permissions`. The `deno_permissions::PermissionsContainer` is put
into the OpState and can be used instead of the current trait-based
permissions system.
For this PR, I've migrated `deno_fetch` to the new crate but kept the
rest of the trait-based system as a wrapper of `deno_permissions` crate.
Doing the migration all at once is error prone and hard to review.
Comparing incremental compile times for `ext/fetch` on Mac M1:
| profile | `cargo build --bin deno` | `cargo plonk build --bin deno` |
| --------- | ------------- | ------------------- |
| `debug` | 20 s | 0.8s |
| `release` | 4 mins 12 s | 1.4s |
|
|
|
|
Fixes https://github.com/denoland/deno_std/issues/4473
|
|
This commit fixes race condition in "node:worker_threads" module were
the first message did a setup of "threadId", "workerData" and
"environmentData".
Now this data is passed explicitly during workers creation and is set up
before any user code is executed.
Closes https://github.com/denoland/deno/issues/22783
Closes https://github.com/denoland/deno/issues/22672
---------
Co-authored-by: Satya Rohith <me@satyarohith.com>
|
|
Not sure if we should do this, but it's a nice hidden tool that
overwrites the working tree with the fast check output.
|
|
In
https://github.com/denoland/deno/pull/22720/files#diff-d62d85de2a7ffb816cd2fdbaa47e588352f521c7c43d058b75649bbb255e0ae1R70
, I copy and pasted from another area of the code and didn't think about
removing how it ignores the vendor folder by default.
|
