I don't have a reliable reproduction for it, but it makes it
painful to use the Jupyter kernel with semi-frequent random panics.
The completions don't always work correctly anyway, so I think
it's better to just not panic here for the time being.
Fixes https://github.com/denoland/deno/issues/26340
<!--
Before submitting a PR, please read
https://docs.deno.com/runtime/manual/references/contributing
1. Give the PR a descriptive title.
Examples of good title:
- fix(std/http): Fix race condition in server
- docs(console): Update docstrings
- feat(doc): Handle nested reexports
Examples of bad title:
- fix #7123
- update docs
- fix bugs
2. Ensure there is a related issue and it is referenced in the PR text.
3. Ensure there are tests that cover the changes.
4. Ensure `cargo test` passes.
5. Ensure `./tools/format.js` passes without changing files.
6. Ensure `./tools/lint.js` passes.
7. Open as a draft PR if your work is still in progress. The CI won't
run
all steps, but you can add '[ci]' to a commit message to force it to.
8. If you would like to run the benchmarks on the CI, add the 'ci-bench'
label.
-->
Some `deno add` and `deno install` example usage commands didn't have
the `jsr:` or `npm:` prefixes.
---------
Signed-off-by: Marvin Hagemeister <marvinhagemeister50@gmail.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
`napi_call_function` should use our equiv of NAPI_PREAMBLE (`&mut Env`
instead of `*mut Env`) since it needs to set error codes based on
whether the body of the function raised a JS exception.
Fixes: https://github.com/denoland/deno/issues/26282
Fixes #26085.
Adds a basic retry utility with some defaults, starts off with a 100ms
wait, then 250ms, then 500ms
I've applied the retry in the http client, reusing an existing function,
so this also applies to retrying downloads of deno binaries in `upgrade`
and `compile`. I can make a separate function that doesn't retry so this
doesn't affect `upgrade` and `compile`, but it seemed desirable to have
retries there too, so I left it in.
This came up on Discord as a question so I thought it's worth adding a
hint for this as it might be a common pitfall.
---------
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
Fixes https://github.com/denoland/deno/issues/26119.
Originally I wanted to put them in package.json if there's no deno.json,
but on second thought it makes more sense to just create a deno.json
This change removes the handling of `--check` and `--no-check` flags from
`deno repl` subcommand.
Currently these flags don't have effects, and the help output for these
options are incorrect and confusing.
closes #26042
This commit fixes the issue of import name conflict in case the named
export and default export have the same name by letting named export
take precedence over default export.
Fixes #26009
When using the `--unstable-detect-cjs` flag or adding `"unstable":
["detect-cjs"]` to a deno.json, it will make a JS file CJS if the
closest package.json contains `"type": "commonjs"` and the file is not
an ESM module (no TLA, no `import.meta`, no `import`/`export`).
Although using `--allow-run` without an allow list gives basically no
security, I think we should remove this warning because it gets in the
way and the only way to disable it is via --quiet.
The exploit `--allow-import` is preventing against requires a
compromised host. To make things easier and given its popularity, we're
going to have the default `--allow-import` value include
`cdn.jsdelivr.net:443`, but this can be overridden by replacing the
`--allow-import` value with something else.
Fixes #25998. Fixes https://github.com/denoland/deno/issues/25928.
Originally I was just going to make this an error message instead of a
panic, but once I got to a minimal repro I felt that this really should
work.
The panic occurs when you have `nodeModulesDir: manual` (or a
package.json present), and you have an npm package with a tag in your
deno.json (see the spec test that illustrates this).
This code path only actually executes when trying to choose an
appropriate package version from `node_modules/.deno`, so we should be
able to fix it by storing some extra data at install time.
The fix proposed here is to repurpose the `.initialized` file that we
store in `node_modules` to store the tags associated with a package.
Basically, if you have a version requirement with a tag (e.g.
`npm:chalk@latest`), when we set up the node_modules folder for that
package, we store the tag (`latest`) in `.initialized`. Then, when doing
BYONM resolution, if we have a version requirement with a tag, we read
that file and check if the tag is present.
The downside is that we do more work when setting up `node_modules`. We
_could_ do this only when BYONM is enabled, but that would have the
downside of needing to re-run `deno install` when you switch from auto
-> manual, though maybe that's not a big deal.
Fixes #25861.
Previously we were attempting to match the version requirement against
the version already present in `node_modules` root, and if they didn't
match we would create a node_modules dir in the workspace member's
directory with the dependency.
Aside from the fact that this caused the panic, on second thought it
just doesn't make sense in general. We shouldn't be semver matching, as
resolution has already occurred and decided what package versions are
required. Instead, we can just compare the versions directly.
Fixes #24740.
Implements the `uv_mutex_*` and `uv_async_*` APIs.
The mutex API is implemented exactly as libuv, a thin wrapper over the
OS's native mutex.
The async API is implemented in terms of napi_async_work. As documented
in the napi docs, you really shouldn't call `napi_queue_async_work`
multiple times (it is documented as undefined behavior). However, our
implementation doesn't have any issue with this, so I believe it suits
our purpose here.
Testing once again if the crates are being properly released.
---------
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Test run before Deno 2.0 release to make sure that the publishing
process passes correctly.
---------
Co-authored-by: bartlomieju <bartlomieju@users.noreply.github.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit adds a suggestion with information and hint how
to resolve situation when user tries to run an npm package
with Node-API addons using global cache (which is currently not
supported).
Closes https://github.com/denoland/deno/issues/25974
Previously the CLI was incorrectly reporting `React` as unused in a JSX
file that uses the "old" transform.
The LSP was already handling this correctly.
`esbuild` can work fine without needing to run post-install script, so
to make it easier on users (especially people using Vite) we are not prompting to run with
`--allow-scripts` again.
We only do that for version >= 0.18.0 to be sure.
Currently we only warn once. With this PR, we continue to warn about
not-run scripts on explicit `deno install` (or cache). For `run` (or
other subcommands) we only warn the once, as we do currently.
Fixes https://github.com/denoland/deno/issues/25862.
npm only makes bin entries executable if they get linked into `.bin`, as
we did before this PR. So this PR actually deviates from npm, because
it's the only reasonable way to fix this that I can think of.
---
The reason this was broken in moment is the following:
Moment has dependencies on two typescript versions: 1.8 and 3.1
If you have two packages with conflicting bin entries (i.e. two
typescript versions which both have a bin entry `tsc`), in npm it is
non-deterministic and undefined which one will end up in `.bin`.
npm, due to implementation differences, chooses to put typescript 1.8
into the `.bin` directory, and so `node_modules/typescript/bin/tsc` ends
up getting marked executable. We, however, choose typescript 3.2, and so
we end up making `node_modules/typescript3/bin/tsc` executable.
As part of its tests, moment executes `node_modules/typescript/bin/tsc`.
Because we didn't make it executable, this fails.
Since the conflict resolution is undefined in npm, instead of trying to
match it, I think it makes more sense to just make bin entries
executable even if they aren't chosen in the case of a conflict.
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>
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.
Refactors the lifecycle scripts code to extract out the common
functionality and then uses that to provide a warning in the global
resolver.
While ideally we would still support them with the global cache, for now
a warning is at least better than the status quo (where people are
unaware why their packages aren't working).
`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
Partially addresses https://github.com/denoland/deno/issues/25648.
This allows packages that use `crossws` to be installed with `deno
install`. `crossws` specifies an optional peer dependency on
`uWebSockets`, but `uWebSockets` is not on npm (it is used with `git:`
or `github:` specifiers). Previously we would error on this, now we
don't error on non-existent optional peer dependencies.
This is for security reasons for the time being for Deno 2. Details to
follow post Deno 2.0 release.
Remote import maps seem incredibly rare (only 2 usages on GitHub from
what I can tell), so we'll add this back with more permissions if
there's enough demand for it:
https://github.com/search?type=code&q=%2F%22importMap%22%3A+%22http%2F
In the meantime, use the `--import-map` flag and `"deno.importMap"`
config in the LSP for remote import maps.
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.
