| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
Closes https://github.com/denoland/deno/issues/16771
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
Co-authored-by: Marvin Hagemeister <marvin@deno.com>
|
|
Adds a new `--lint` flag to `deno doc` that surfaces three kinds of
diagnostics:
1. Diagnostic for non-exported type referenced in an exported type.
* Why? People often forget to export types from a module in TypeScript.
To supress this diagnostic, add an `@internal` jsdoc tag to the internal
type.
1. Diagnostic for missing return type or missing property type on a
**public** type.
* Why? Otherwise `deno doc` will not display good documentation. Adding
explicit types also helps with type checking performance.
1. Diagnostic for missing jsdoc on a **public** type.
* Why? Everything should be documented. This diagnostic can be supressed
by adding a jsdoc comment description.
If the lint passes, `deno doc` generates documentation as usual.
For example, checking for deno doc diagnostics on the CI:
```shellsession
$ deno doc --lint mod.ts second_entrypoint.ts > /dev/null
```
This feature is incredibly useful for library authors.
## Why not include this in `deno lint`?
1. The command needs the documenation output in order to figure out the
diagnostics.
1. `deno lint` doesn't understand where the entrypoints are. That's
critical for the diagnostics to be useful.
1. It's much more performant to do this while generating documentation.
1. There is precedence in rustdoc (ex. `#![warn(missing_docs)]`).
## Why not `--check`?
It is confusing with `deno run --check`, since that means to run type
checking (and confusing with `deno check --docs`).
## Output Future Improvement
The output is not ideal atm, but it's fine for a first pass. We will
improve it in the future.
Closes https://github.com/denoland/deno_lint/pull/972
Closes https://github.com/denoland/deno_lint/issues/970
Closes https://github.com/denoland/deno/issues/19356
|
|
|
|
This commit adds `--unstable-hmr` flag, that enabled Hot Module Replacement.
This flag works like `--watch` and accepts the same arguments. If
HMR is not possible the process will be restarted instead.
Currently HMR is only supported in `deno run` subcommand.
Upon HMR a `CustomEvent("hmr")` will be dispatched that contains
information which file was changed in its `details` property.
---------
Co-authored-by: Valentin Anger <syrupthinker@gryphno.de>
Co-authored-by: David Sherret <dsherret@gmail.com>
|
|
This commit adds support for multiple entry points to `deno doc`.
Unfortunately to achieve that, I had to change the semantics of the
command to explicitly require `--filter` parameter for filtering
symbols, instead of treating second free argument as the filter argument.
`deno doc --builtin` is still supported, but cannot be mixed with
actual entrypoints.
|
|
Remove usage of Chrono's clock feature which pulls in iana-time-zone ->
core-foundation
|
|
Upgrades to deno_doc 0.70 which includes the feature for showing
non-exported types referenced in exported types as well as a much more
advanced deno doc that uses a symbol graph.
|
|
As title. This will help use the two independently from the other, which
will help in an upcoming deno doc PR where I need to parse the source
files with scope analysis.
|
|
This PR adds a new unstable "bring your own node_modules" (BYONM)
functionality currently behind a `--unstable-byonm` flag (`"unstable":
["byonm"]` in a deno.json).
This enables users to run a separate install command (ex. `npm install`,
`pnpm install`) then run `deno run main.ts` and Deno will respect the
layout of the node_modules directory as setup by the separate install
command. It also works with npm/yarn/pnpm workspaces.
For this PR, the behaviour is opted into by specifying
`--unstable-byonm`/`"unstable": ["byonm"]`, but in the future we may
make this the default behaviour as outlined in
https://github.com/denoland/deno/issues/18967#issuecomment-1761248941
This is an extremely rough initial implementation. Errors are
terrible in this and the LSP requires frequent restarts. Improvements
will be done in follow up PRs.
|
|
|
|
Upgrades to deno_ast 0.30.
|
|
closes #20566
|
|
This commit introduces "WatcherCommunicator" struct that
is used facilitate bi-directional communication between CLI
file watcher and the watched function.
Prerequisite for https://github.com/denoland/deno/pull/20876
|
|
This brings in [`display`](https://github.com/rgbkrk/display.js) as part
of the `Deno.jupyter` namespace.
Additionally these APIs were added:
- "Deno.jupyter.md"
- "Deno.jupyter.html"
- "Deno.jupyter.svg"
- "Deno.jupyter.format"
These APIs greatly extend capabilities of rendering output in Jupyter
notebooks.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
|
|
|
|
|
|
Getting closer...
|
|
Allows `Jupyter.display` to return a promise.
Example:
```javascript
class WikiPage {
constructor(public name) {}
async [Symbol.for("Jupyter.display")]() {
let response = await fetch("https://en.wikipedia.org/wiki/" + this.name);
return { "text/html": await response.text() }
}
}
new WikiPage("Deno_(software)")
```
|
|
Changes logo prefix from `icon-*` to `logo-*` so they are correctly
discovered by Jupyter.
|
|
|
|
|
|
|
|
This fixes #20767.
We were losing `this` and then when an exception was happening, it
didn't show up in the output because we weren't bubbling up exceptions
from within a user defined function for displaying. I thought about
doing a `.call(object)` but didn't want to get in the way of a bound
`this` that a user or library was already putting on the function.
|
|
Adds `buffers` to the `Deno.jupyter.broadcast` API to send binary data
via comms. This affords the ability to send binary data via websockets
to the jupyter widget frontend.
|
|
managed `CliNpmResolver` (#20777)
Part of https://github.com/denoland/deno/issues/18967
|
|
internal to `npm::managed` (#20764)
|
|
Creates the `cli::npm::managed` module and starts moving more
functionality into it.
|
|
(#20714)
Exposes
[`metadata`](https://jupyter-client.readthedocs.io/en/latest/messaging.html#metadata)
to the `Deno.jupyter.broadcast` API.
```js
await Deno.jupyter.broadcast(msgType, content, metadata);
```
The metadata is required for
[`"comm_open"`](https://github.com/jupyter-widgets/ipywidgets/blob/main/packages/schema/messages.md#instantiating-a-widget-object-1)
for with `jupyter.widget` target.
|
|
This makes `CliNpmResolver` a trait. The terminology used is:
- **managed** - Deno manages the node_modules folder and does an
auto-install (ex. `ManagedCliNpmResolver`)
- **byonm** - "Bring your own node_modules" (ex. `ByonmCliNpmResolver`,
which is in this PR, but unimplemented at the moment)
Part of #18967
|
|
This is required from BYONM (bring your own node_modules).
Part of #18967
|
|
|
|
This is what we do for deno install, so it should be fine here
https://github.com/denoland/deno_install/pull/219
Closes https://github.com/denoland/deno/issues/20683
|
