| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Luca Casonato <lucacasonato@yahoo.com>
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sloppily (#21506)
|
|
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
One warning for when using it with `deno compile` and another when using
it with `deno run`.
|
|
|
|
for a directory, and TS files from JS extensions (#21464)
Adds an `--unstable-sloppy-imports` flag which supports the
following for `file:` specifiers:
* Allows writing `./mod` in a specifier to do extension probing.
- ex. `import { Example } from "./example"` instead of `import { Example
} from "./example.ts"`
* Allows writing `./routes` to do directory extension probing for files
like `./routes/index.ts`
* Allows writing `./mod.js` for *mod.ts* files.
This functionality is **NOT RECOMMENDED** for general use with Deno:
1. It's not as optimal for perf:
https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-2/
1. It makes tooling in the ecosystem more complex in order to have to
understand this.
1. The "Deno way" is to be explicit about what you're doing. It's better
in the long run.
1. It doesn't work if published to the Deno registry because doing stuff
like extension probing with remote specifiers would be incredibly slow.
This is instead only recommended to help with migrating existing
projects to Deno. For example, it's very useful for getting CJS projects
written with import/export declaration working in Deno without modifying
module specifiers and for supporting TS ESM projects written with
`./mod.js` specifiers.
This feature will output warnings to guide the user towards correcting
their specifiers. Additionally, quick fixes are provided in the LSP to
update these specifiers:
|
|
A bit hacky, but it works. Essentially, this will check for all the
scripts in the node_modules/.bin directory then force them to run with
Deno via deno_task_shell.
|
|
directory (#21479)
Part of https://github.com/denoland/deno/issues/21476
|
|
Prerequisite for https://github.com/denoland/deno/pull/18453.
This update also makes it possible to address
https://github.com/denoland/deno/issues/8049 by
using
https://docs.rs/rustyline/latest/rustyline/struct.Editor.html#method.create_external_printer
|
|
one (#21470)
|
|
Extracting some refactorings for the module work that will land in
https://github.com/denoland/deno_core/pull/359/
|
|
|
|
|
|
|
|
This PR causes Deno to include more files in the graph based on how a
template literal looks that's provided to a dynamic import:
```ts
const file = await import(`./dir/${expr}`);
```
In this case, it will search the `dir` directory and descendant
directories for any .js/jsx/etc modules and include them in the graph.
To opt out of this behaviour, move the template literal to a separate
line:
```ts
const specifier = `./dir/${expr}`
const file = await import(specifier);
```
|
|
|
|
|
|
The self-upgrade feature is undesirable when deno is installed from
(Linux) distribution repository - using a system package manager. This
change will allow package maintainers to build deno with the "upgrade"
subcommand and background check disabled.
When the user runs `deno upgrade <args>` and the upgrade feature is
disabled, it will exit with error message explaining that this deno
binary was built without the upgrade feature.
Note: This patch is already used in the Alpine Linux’s
[deno](https://pkgs.alpinelinux.org/packages?name=deno) package.
|
|
Not tested thoroughly. This is a good start.
Closes #21350
|
|
|
|
|
|
|
|
Co-authored-by: David Sherret <dsherret@gmail.com>
Co-authored-by: Luca Casonato <lucacasonato@yahoo.com>
Co-authored-by: Luca Casonato <hello@lcas.dev>
|
|
1. Adds an upgrade prompt integration test.
1. Adds a test for when the upgrade check takes a long time in the repl.
|
|
Fixes #20528
|
|
|
|
|
|
Closes #21109
|
|
|
|
|
|
Closes #21160
|
|
This also updates deno_graph, which has the JSR change to use "exports".
It's not yet useful atm, so I've made this PR a fix about the deno doc
--lint error message improvements. I'll do a follow-up PR that adds
exports to the deno.json
|
|
This commit moves all Chrome Devtools Protocol messages to `cli/cdp.rs`
and refactors all places using these types to pull them from a common
place.
No functional changes.
|
|
As pointed out in https://github.com/denoland/deno/issues/21067 , it's
confusing that `deno doc --lint mod.ts` outputs the documentation to
stdout on success. Instead, it would be better if it outputted how many
files were checked similar to what `deno lint` does on success. It still
outputs the documentation if `--lint` or `--html` are provided so this
is non-breaking.
|
|
I made some fixes in deno_ast to make this possible and we forgot to
update this.
|
|
Co-authored-by: Marvin Hagemeister <marvin@deno.com>
|
|
Closes https://github.com/denoland/deno/issues/21022
|
|
This commit adds static documentation site generate to "deno doc"
subcommand.
Example:
```
$ deno doc --html --name="My library" ./mod.ts
# outputs to ./docs/
$ deno doc --html --name="My library" --output=./documentation/ ./mod.ts ./file2.js
# outputs to ./documentation/
$ deno doc --html --name="My library" ./**/mod.ts
# generate docs for all files with "mod.ts" name
```
Closes https://github.com/denoland/deno/issues/8233
|
