| Age | Commit message (Collapse) | Author |
|---|
|
Closes #20413
|
|
This PR adds a test reporter for the [Test Anything
Protocol](https://testanything.org).
It makes the following implementation decisions:
- No TODO pragma, as there is no such marker in `Deno.test`
- SKIP pragma for `ignore`d tests
- Test steps are treated as TAP14 subtests
- Support for this in consumers seems spotty
- Some consumers will incorrectly interpret these markers, resulting in
unexpected output
- Considering the lack of support, and to avoid implementation
complexity,
subtests are at most one level deep (all test steps are in the same
subtest)
- To accommodate consumers that use comments to indicate test-suites
(unspecced)
- The test module path is output as a comment
- This is disabled for `--parallel` testing
- Failure diagnostics are output as JSON, which is also valid YAML
- The structure is not specified, so the format roughly follows the spec
example:
```
---
message: "Failed with error 'hostname peebles.example.com not found'"
severity: fail
found:
hostname: 'peebles.example.com'
address: ~
wanted:
hostname: 'peebles.example.com'
address: '85.193.201.85'
at:
file: test/dns-resolve.c
line: 142
...
```
|
|
Moved the configuration file to https://github.com/denoland/deno_config
as we will have to use it in other projects.
|
|
present in `deno run` (#20145)
Fix #20022, fix #19627 (duplicate)
#17333 upgraded clap from version 3.1 to version 4. clap version 3.2.0
(intentionally) broke a behavior that deno was relying on to make `deno
run --v8-flags=--help` work without specifying a file, see
clap-rs/clap#3793. The workaround was to make the script argument
required _unless_ `--v8-flags` is present. This broke the expectation
that all successfully parsed `run` commands have the script argument
set, leading to the panic on
`matches.remove_many::<String>("script_arg").unwrap()`.
Clap, as far as I was able to find out, does not currently offer a neat
solution to this problem. This PR adds logic to create and return a
custom clap error when a parsed run command does not have the script
argument.
I added an appropriate test.
|
|
Renames the unstable `deno_modules` directory and corresponding settings
to `vendor` after feedback. Also causes the vendoring of the
`node_modules` directory which can be disabled via
`--node-modules-dir=false` or `"nodeModulesDir": false`.
|
|
This commit adds new "--deny-*" permission flags. These are complimentary to
"--allow-*" flags.
These flags can be used to restrict access to certain resources, even if they
were granted using "--allow-*" flags or the "--allow-all" ("-A") flag.
Eg. specifying "--allow-read --deny-read" will result in a permission error,
while "--allow-read --deny-read=/etc" will allow read access to all FS but the
"/etc" directory.
Runtime permissions APIs ("Deno.permissions") were adjusted as well, mainly
by adding, a new "PermissionStatus.partial" field. This field denotes that
while permission might be granted to requested resource, it's only partial (ie.
a "--deny-*" flag was specified that excludes some of the requested resources).
Eg. specifying "--allow-read=foo/ --deny-read=foo/bar" and then querying for
permissions like "Deno.permissions.query({ name: "read", path: "foo/" })"
will return "PermissionStatus { state: "granted", onchange: null, partial: true }",
denoting that some of the subpaths don't have read access.
Closes #18804.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Nayeem Rahman <nayeemrmn99@gmail.com>
|
|
This commit adds "--reporter" and "--junit-path" flags to "deno test"
subcommand instead of using "--dot" and "--junit" flags.
|
|
This commit adds a "dot" reporter to "deno test" subcommand,
that can be activated using "--dot" flag.
It provides a concise output using:
- "." for passing test
- "," for ignored test
- "!" for failing test
User output is silenced and not printed to the console.
In non-TTY environments each result is printed on a separate line.
|
|
Closes #15633
|
|
|
|
|
|
This commit makes the following changes
- Created a `CompoundTestReporter` to allow us to use multiple reporters
- Implements `JUnitTestReporter` which writes JUnit XML to a path
- Added a CLI flag/option `--junit` that enables JUnit reporting. By
default this writes the report to `stdout` (and disables pretty
reporting). If a path is provided, it will write the JUnit report to
that file while the pretty reporter writes to stdout like normal
Output of `deno -- test --allow-all --unstable
--location=http://js-unit-tests/foo/bar --junit
cli/tests/unit/testing_test.ts `
```xml
<?xml version="1.0" encoding="UTF-8"?>
<testsuites name="deno test" tests="7" failures="0" errors="0" time="0.176">
<testsuite name="file:///Users/cooper/deno/deno/cli/tests/unit/testing_test.ts" tests="7" disabled="0" errors="0" failures="0">
<testcase name="testWrongOverloads" time="0.012">
</testcase>
<testcase name="nameOfTestCaseCantBeEmpty" time="0.009">
</testcase>
<testcase name="invalidStepArguments" time="0.008">
</testcase>
<testcase name="nameOnTextContext" time="0.029">
<properties>
<property name="step[passed]" value="step ... nested step"/>
<property name="step[passed]" value="step"/>
</properties>
</testcase>
<testcase name="originOnTextContext" time="0.030">
<properties>
<property name="step[passed]" value="step ... nested step"/>
<property name="step[passed]" value="step"/>
</properties>
</testcase>
<testcase name="parentOnTextContext" time="0.030">
<properties>
<property name="step[passed]" value="step ... nested step"/>
<property name="step[passed]" value="step"/>
</properties>
</testcase>
<testcase name="explicit undefined for boolean options" time="0.009">
</testcase>
</testsuite>
</testsuites>
```
|
|
|
|
|
|
Moves the watch setting out of the `Flags` struct and into the
individual subcommands
|
|
Closes #19468
|
|
Also switches to use defer for all subcommands besides run.
|
|
|
|
We never properly added support for this. This fixes vendoring when it
has npm or node specifiers. Vendoring occurs by adding a
`"nodeModulesDir": true` property to deno.json then it uses a local
node_modules directory. This can be opted out by setting
`"nodeModulesDir": false` or running with `--node-modules-dir=false`.
Closes #18090
Closes #17210
Closes #17619
Closes #16778
|
|
This adds an option to disable or enable using a local `node_modules`
directory as a project wide setting.
https://github.com/denoland/manual/pull/659
Closes #17930
|
|
This is the initial support for npm and node specifiers in `deno
compile`. The npm packages are included in the binary and read from it via
a virtual file system. This also supports the `--node-modules-dir` flag,
dependencies specified in a package.json, and npm binary commands (ex.
`deno compile --unstable npm:cowsay`)
Closes #16632
|
|
Hey there! I took a crack at improving these embedded docs [as requested
here](https://github.com/denoland/deno/issues/18685). These should
accurately reflect the functionality of the permission-related flags for
`deno run`.
### Highlights
* Adds human-readable argument string in the format [prescribed in the
docs](https://docs.rs/clap/latest/clap/struct.Arg.html#method.value_name)
* Keeps text description terse, but includes a relevant copy/pasteable
docs link
* Includes example argument usage/formatting
|
|
|
|
The CLI docs suggested that all deno subcommands no longer type-check by
default. This is only the case for some subcommands, and this PR
clarifies the CLI docs in this regard.
|
|
1. Fixes a cosmetic issue in the repl where it would display lsp warning
messages.
2. Lazily loads dependencies from the package.json on use.
3. Supports using bare specifiers from package.json in the REPL.
Closes #17929
Closes #18494
|
|
This `Lazy<String>` calls were showing up on flamegraph and there's
really no point in using them.
|
|
|
|
|
|
These caused a bunch of unnecessary allocations on each startup.
|
|
Adds `--ext` to `deno run`, closes #5088
Additionally
- Adds `--ext` to `deno compile` and `deno bundle`
|
|
This change will enable dynamic imports and web workers to use modules
not reachable from the main module, by passing a list of extra side
module roots as options to `deno compile`.
This can be done by specifying "--include" flag that accepts a file path or a
URL. This flag can be specified multiple times, to include several modules.
The modules specified with "--include" flag, will be added to the produced
"eszip".
|
|
This PR _**temporarily**_ removes WebGPU (which has behind the
`--unstable` flag in Deno), due to performance complications due to its
presence.
It will be brought back in the future; as a point of reference, Chrome
will ship WebGPU to stable on 26/04/2023.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
This commit changes current "deno_core::resolve_url_or_path" API to
"resolve_url_or_path_deprecated" and adds new "resolve_url_or_path"
API that requires to explicitly pass the directory from which paths
should be resolved to.
Some of the call sites were updated to use the new API, the reminder
of them will be updated in a follow up PR.
Towards landing https://github.com/denoland/deno/pull/15454
|
|
Closes #18159
|
|
Add space between period and "Any" in `--v8-flags` help text.
|
|
Depends on #17924
Part of #17916
|
|
language server (#17891)
|
|
This is a super basic initial implementation. We don't create a
`node_modules/.bin` folder at the moment and add it to the PATH like we
should which is necessary to make command name resolution in the
subprocess work properly (ex. you run a script that launches another
script that then tries to launch an "npx command"... this won't work
atm).
Closes #17492
|
|
This commits adds auto-discovery of "package.json" file when running
"deno run" and "deno task" subcommands. In case of "deno run" the
"package.json" is being looked up starting from the directory of the
script that is being run, stopping early if "deno.json(c)" file is found
(ie. FS tree won't be traversed "up" from "deno.json").
When "package.json" is discovered the "--node-modules-dir" flag is
implied, leading to creation of local "node_modules/" directory - we
did that, because most tools relying on "package.json" will expect
"node_modules/" directory to be present (eg. Vite). Additionally
"dependencies" and "devDependencies" specified in the "package.json"
are downloaded on startup.
This is a stepping stone to supporting bare specifier imports, but
the actual integration will be done in a follow up commit.
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
This PR removes the `UNSTABLE` mentions from the CLI docs for `deno test
--coverage/doc/shuffle`.
|
|
This commit adds a deprecation warning when using "deno bundle"
subcommand and removes it from the output of "deno help".
|
|
|
|
Make deno fmt options CLI args less verbose #17546
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
Closes #5669
|
|
Allows to change behavior of `deno fmt` to use "ASI" setting for
semicolons instead of always prefering them, this is done
by "--options-semi=asi" flag or `"semi": "asi"` setting
in the config file.
|
|
The way the standalone mode handles the `--cert` flag is different to
all other modes. This is because `--cert` takes a path to the
certificate file, which is directly added to the root cert store; except
for compile mode, where its byte contents are stored in the standalone
metadata, and they are added to the root cert store after the
`ProcState` is created.
This change instead changes `Flags::ca_file` (an `Option<String>`) into
`Flags::ca_data`, which can represent a `String` file path or a
`Vec<u8>` with the certificate contents. That way, standalone mode can
create a `ProcState` whose root cert store alreay contains the
certificate.
This change also adds a tests for certificates in standalone mode, since
there weren't any before.
This refactor will help with implementing web workers in standalone mode
in the future.
|
|
Closes https://github.com/denoland/deno/issues/2699
Closes https://github.com/denoland/deno/issues/2347
Uses unstable rustfmt features. Since dprint invokes `rustfmt` we do not
need to switch the cargo toolchain to nightly. Do we care about
formatting stability of our codebase across Rust versions? (I don't)
|
