| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
test`, etc) (#26075)
Fixes https://github.com/denoland/deno/issues/25533. Fixes
https://github.com/denoland/deno/issues/25396.
Previously we only supported it on `deno install` and `deno cache`,
which is annoying if you're using `nodeModulesDir: auto`.
Also changes from printing output of lifecycle scripts directly to
capturing the output and only printing it on error.
|
|
|
|
Fixes https://github.com/denoland/deno/issues/26120
|
|
Closes https://github.com/denoland/deno/issues/24421
|
|
|
|
|
|
Some more slow progress on moving all the resolution code into
deno_resolver.
|
|
This is slow progress towards creating a `deno_resolver` crate.
Waiting on:
* https://github.com/denoland/deno/pull/25918
* https://github.com/denoland/deno/pull/25916
|
|
|
|
|
|
|
|
|
|
This replaces `--allow-net` for import permissions and makes the
security sandbox stricter by also checking permissions for statically
analyzable imports.
By default, this has a value of
`--allow-import=deno.land:443,jsr.io:443,esm.sh:443,raw.githubusercontent.com:443,gist.githubusercontent.com:443`,
but that can be overridden by providing a different set of hosts.
Additionally, when no value is provided, import permissions are inferred
from the CLI arguments so the following works because
`fresh.deno.dev:443` will be added to the list of allowed imports:
```ts
deno run -A -r https://fresh.deno.dev
```
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
We weren't surfacing dependency errors in types files of js files.
|
|
npm:pkg` (#25858)
Fixes #25813.
I initially tried doing this in `deno_semver`, where it's a cleaner
change, but that caused breakage in deno in places where we don't expect
a tag (see https://github.com/denoland/deno/issues/25857).
This does not fix wildcard requirements failing to choose pre-release
versions. That's a little more involved and I'll do a separate PR.
|
|
Improves syntax errors for HTML formatter.
`broken.html`
```html
<div class=container > content
```
```
$ deno fmt broken.html
Error formatting: /Users/ib/dev/deno/tests/specs/fmt/html/broken.html
syntax error 'expect close tag' at line 3, column 0
Checked 1 file
```
```
$ ./target/debug/deno fmt broken.html
Error formatting: /Users/ib/dev/deno/tests/specs/fmt/html/broken.html
Syntax error (expect close tag) at file:///Users/ib/dev/deno/tests/specs/fmt/html/broken.html:3:0
Checked 1 file
```
|
|
`deno fmt --check` was broken for CSS, YAML and HTML files.
Before this PR, formatting any of these file types would return a
string, even though the contract in `cli/tools/fmt.rs` is to only return a
string if the formatting changed. This causes wrong flagging of these files
as being badly formatted even though diffs showed nothing (because
they were in fact formatted properly).
Closes https://github.com/denoland/deno/issues/25840
|
|
Fixes #25802
markup_fmt plugin supports some HTML-like formats like Angular, Jinja,
Twig, Nunjucks or Vento, that are not supported by `deno fmt`. This PR
adds support for the extensions `njk` (Nunjucks) and `vto` (Vento).
Angular doesn't have a custom extension (it uses `html` afaik) and Jinja
and Twig are template engines written in Python and PHP respectively so
it doesn't make sense to be supported by Deno.
|
|
This commits stabilizes CSS, HTML and YAML formatters
in `deno fmt`.
It is no longer required to use either of these flags:
- `--unstable-css`
- `--unstable-html`
- `--unstable-yaml`
Or these `unstable` options in the config file:
- `fmt-css`
- `fmt-html`
- `html-yaml`
|
|
|
|
default (#25721)
When using the `ext` flag, it will still attempt formatting them with
the provided extension
|
|
scenarios (#25472)
Closes #11220
Currently does lint, fmt, and repl
|
|
|
|
|
|
This commit lets `deno test --doc` command actually evaluate code snippets in
JSDoc and markdown files.
## How it works
1. Extract code snippets from JSDoc or code fences
2. Convert them into pseudo files by wrapping them in `Deno.test(...)`
3. Register the pseudo files as in-memory files
4. Run type-check and evaluation
We apply some magic at the step 2 - let's say we have the following file named
`mod.ts` as an input:
````ts
/**
* ```ts
* import { assertEquals } from "jsr:@std/assert/equals";
*
* assertEquals(add(1, 2), 3);
* ```
*/
export function add(a: number, b: number) {
return a + b;
}
````
This is virtually transformed into:
```ts
import { assertEquals } from "jsr:@std/assert/equals";
import { add } from "files:///path/to/mod.ts";
Deno.test("mod.ts$2-7.ts", async () => {
assertEquals(add(1, 2), 3);
});
```
Note that a new import statement is inserted here to make `add` function
available. In a nutshell, all items exported from `mod.ts` become available in
the generated pseudo file with this automatic import insertion.
The intention behind this design is that, from library user's standpoint, it
should be very obvious that this `add` function is what this example code is
attached to. Also, if there is an explicit import statement like
`import { add } from "./mod.ts"`, this import path `./mod.ts` is not helpful for
doc readers because they will need to import it in a different way.
The automatic import insertion has some edge cases, in particular where there is
a local variable in a snippet with the same name as one of the exported items.
This case is addressed by employing swc's scope analysis (see test cases for
more details).
## "type-checking only" mode stays around
This change will likely impact a lot of existing doc tests in the ecosystem
because some doc tests rely on the fact that they are not evaluated - some cause
side effects if executed, some throw errors at runtime although they do pass the
type check, etc. To help those tests gradually transition to the ones runnable
with the new `deno test --doc`, we will keep providing the ability to run
type-checking only via `deno check --doc`. Additionally there is a `--doc-only`
option added to the `check` subcommand too, which is useful when you want to
type-check on code snippets in markdown files, as normal `deno check` command
doesn't accept markdown.
## Demo
https://github.com/user-attachments/assets/47e9af73-d16e-472d-b09e-1853b9e8f5ce
---
Closes #4716
|
|
Closes #22583
|
|
This makes the permission system more versatile.
|
|
Fixes https://github.com/denoland/deno/issues/25632
Exit code 1 indiciates some sort of failure but `deno task` (without
arguments) is used to list available commands.
---------
Co-authored-by: Yoshiya Hinosawa <stibium121@gmail.com>
|
|
|
|
Signed-off-by: David Sherret <dsherret@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
Co-authored-by: crowlkats <crowlkats@toaxl.com>
|
|
This PR addresses issue #25534
**Code Changes**
- Updated malva version to the latest in cli/Cargo.toml.
- Updated LanguageOptions to match new Malva config.
- Added test case same as the issue to assure changes success.
|
|
Towards #22079
---------
Signed-off-by: Asher Gomez <ashersaupingomez@gmail.com>
|
|
This commit effectively removes the --unstable flag.
It's still being parsed, but it only prints a warning that a granular
flag should be used instead and doesn't actually enable any
unstable feature.
Closes https://github.com/denoland/deno/issues/25485
Closes https://github.com/denoland/deno/issues/23237
|
|
Fixes #25176
|
|
|
|
```
deno install --dev npm:chalk
```
Adds to `devDependencies` if a `package.json` is present, otherwise it
just adds to `imports` in `deno.json`
|
|
Closes https://github.com/denoland/deno/issues/25321
Ended up being a larger refactoring, since we're now juggling
(potentially) two config files in the same `add`, instead of choosing
one. I don't love the shape of the code, but I think it's good enough
Some smaller side improvements:
- `deno remove` supports `jsonc`
- `deno install --dev` will be a really simple change
- if `deno remove` removes the last import/dependency in the
`imports`/`dependencies`/`devDependencies` field, it removes the field
instead of leaving an empty object
|
|
The map field has been empty for years now and we don't want the emit
file to be exposed so it allows us to iterate on making the cache
faster. Additionally, it's racy/unreliable to rely on this information.
Instead, people should emit the TS files themselves using tools like
deno_emit, typescript, esbuild, etc.
Closes https://github.com/denoland/deno/issues/17703
|
|
Close https://github.com/denoland/deno/issues/25457
|
|
Towards #22079
---------
Signed-off-by: Asher Gomez <ashersaupingomez@gmail.com>
|
|
Towards #22079
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
```
deno install --entrypoint one.ts two.ts
```
effectively equivalent to `deno cache`
|
|
Deno has been using a deny list, which doesn't make sense because a lot
of these options don't even work.
Closes #25363
|
|
These now works:
```
$ deno add @std/dotenv/load
$ deno add npm:preact/hooks
```
Previously we were erroring out, because this is a "package reference"
including
a subpath.
Closes https://github.com/denoland/deno/issues/25385
---------
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
|
