From upgrading `deno_lint`.
Previously if you had a node project that used a bunch of node globals
(`process.env`, etc), you would have to fix the errors by hand. This PR
includes a new lint that detects usages of node globals (`process`,
`setImmediate`, `Buffer`, etc.) and provides an autofix to import the
correct value. For instance:
```ts
// main.ts
const _foo = process.env.FOO;
```
`deno lint` gives you
```ts
error[no-node-globals]: NodeJS globals are not available in Deno
--> /home/foo.ts:1:14
|
1 | const _foo = process.env.FOO;
| ^^^^^^^
= hint: Add `import process from "node:process";`
docs: https://lint.deno.land/rules/no-node-globals
Found 1 problem (1 fixable via --fix)
Checked 1 file
```
And `deno lint --fix` adds the import for you:
```ts
// main.ts
import process from "node:process";
const _foo = process.env.FOO;
```
In preparation for https://github.com/denoland/deno/pull/25014, this
commit removes public `is_canary()` method and instead uses an enum
`ReleaseChannel` to be able to designate more "kinds" of builds.
Adds a `parallel` flag to `deno serve`. When present, we spawn multiple
workers to parallelize serving requests.
```bash
deno serve --parallel main.ts
```
Currently on linux we use `SO_REUSEPORT` and rely on the fact that the
kernel will distribute connections in a round-robin manner.
On mac and windows, we sort of emulate this by cloning the underlying
file descriptor and passing a handle to each worker. The connections
will not be guaranteed to be fairly distributed (and in practice almost
certainly won't be), but the distribution is still spread enough to
provide a significant performance increase.
---
(Run on an Macbook Pro with an M3 Max, serving `deno.com`
baseline::
```
❯ wrk -d 30s -c 125 --latency http://127.0.0.1:8000
Running 30s test @ http://127.0.0.1:8000
2 threads and 125 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 239.78ms 13.56ms 330.54ms 79.12%
Req/Sec 258.58 35.56 360.00 70.64%
Latency Distribution
50% 236.72ms
75% 248.46ms
90% 256.84ms
99% 268.23ms
15458 requests in 30.02s, 2.47GB read
Requests/sec: 514.89
Transfer/sec: 84.33MB
```
this PR (`with --parallel` flag)
```
❯ wrk -d 30s -c 125 --latency http://127.0.0.1:8000
Running 30s test @ http://127.0.0.1:8000
2 threads and 125 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 117.40ms 142.84ms 590.45ms 79.07%
Req/Sec 1.33k 175.19 1.77k 69.00%
Latency Distribution
50% 22.34ms
75% 223.67ms
90% 357.32ms
99% 460.50ms
79636 requests in 30.07s, 12.74GB read
Requests/sec: 2647.96
Transfer/sec: 433.71MB
```
This commit adds capability to format HTML, Svelte, Vue, Astro and Angular
files.
"--unstable-html" is required to format HTML files, and "--unstable-component"
flag is needed to format other formats. These can also be specified in the config
file.
Close #25015
This commit fixes output of `deno upgrade` subcommand,
by displaying proper version numbers. Before this PR we were
prepending "v" before the canary version hash, which was
obviously wrong.
This commit fixes errors on CI like this:
```
---- upgrade::upgrade_prompt stdout ----
command /home/runner/work/deno/deno/target/release/deno run --log-level=debug main.js
command cwd /tmp/deno-cli-testqDw5UR
command /home/runner/work/deno/deno/target/release/deno run --log-level=debug main.js
command cwd /tmp/deno-cli-testqDw5UR
------ Start Full Text ------
"DEBUG RS - deno::args:620 - No .npmrc file found\r\nDEBUG RS - deno::args:909 - Finished config loading.\r\nDEBUG RS - deno::cache::cache_db:168 - Opening cache /tmp/deno-cli-testMKnYXP/dep_analysis_cache_v2...\r\nDEBUG RS - deno::cache::cache_db:168 - Opening cache /tmp/deno-cli-testMKnYXP/node_analysis_cache_v2...\r\nDEBUG RS - deno::cache::cache_db:168 - Opening cache /tmp/deno-cli-testMKnYXP/v8_code_cache_v2...\r\nDEBUG RS - deno::js:10 - Deno isolate init with snapshots.\r\nDEBUG RS - deno::worker:183 - main_module file:///tmp/deno-cli-testqDw5UR/main.js\r\nDEBUG RS - deno::module_loader:158 - Preparing module load.\r\nDEBUG RS - deno::module_loader:162 - Building module graph.\r\nDEBUG RS - deno::file_fetcher:573 - FileFetcher::fetch_no_follow_with_options - specifier: file:///tmp/deno-cli-testqDw5UR/main.js\r\nDEBUG RS - deno::module_loader:208 - Prepared module load.\r\nDEBUG RS - deno_runtime::worker:739 - received module evaluate Ok(\r\n (),\r\n)\r\nDEBUG RS - deno::module_loader:831 - Updating V8 code cache for ES module: file:///tmp/deno-cli-testqDw5UR/main.js, [1577979522354460122]\r\n"
------- End Full Text -------
Next text: "DEBUG RS - deno::args:620 - No .npmrc file found\r\nDEBUG RS - deno::args:909 - Finished config loading.\r\nDEBUG RS - deno::cache::cache_db:168 - Opening cache /tmp/deno-cli-testMKnYXP/dep_analysis_cache_v2...\r\nDEBUG RS - deno::cache::cache_db:168 - Opening cache /tmp/deno-cli-testMKnYXP/node_analysis_cache_v2...\r\nDEBUG RS - deno::cache::cache_db:168 - Opening cache /tmp/deno-cli-testMKnYXP/v8_code_cache_v2...\r\nDEBUG RS - deno::js:10 - Deno isolate init with snapshots.\r\nDEBUG RS - deno::worker:183 - main_module file:///tmp/deno-cli-testqDw5UR/main.js\r\nDEBUG RS - deno::module_loader:158 - Preparing module load.\r\nDEBUG RS - deno::module_loader:162 - Building module graph.\r\nDEBUG RS - deno::file_fetcher:573 - FileFetcher::fetch_no_follow_with_options - specifier: file:///tmp/deno-cli-testqDw5UR/main.js\r\nDEBUG RS - deno::module_loader:208 - Prepared module load.\r\nDEBUG RS - deno_runtime::worker:739 - received module evaluate Ok(\r\n (),\r\n)\r\nDEBUG RS - deno::module_loader:831 - Updating V8 code cache for ES module: file:///tmp/deno-cli-testqDw5UR/main.js, [1577979522354460122]\r\n"
thread 'upgrade::upgrade_prompt' panicked at tests/integration/upgrade_tests.rs:251:9:
Timed out.
```
These errors are caused by the fact that the test server doesn't have an
endpoint to return
RC releases. Which in turn causes an error to be raised which later just
short-circuits logic
for checking the version and storing it in file. Since fetching from a
remote host is always
fallible I elected to just return an empty vec of "rc" versions instead
of erroring. This might
lead to a slight mismatch in some situation when the request actually
failed and user is
prompted that there's a new canary version, but that is better than not
displaying
prompt at all. This issue will be fixed more robustly once we move to
using SUI for
specifying version of the binary.
This commit adds the "--rc" flag to "deno upgrade" subcommand.
This flag allows to upgrade to the latest "release candidate" release.
The update checker was also updated to take this into account.
This commit stabilizes HMR functionality and renames
`--unstable-hmr` to `--watch-hmr`. The `--unstable-hmr`
flag is still working, but hidden from the help output.
It will be removed in Deno 2.
Once https://github.com/denoland/deno/pull/24958 lands
we should improve grouping of `--watch` and `--watch-hmr`
flags.
This PR integrates [Malva](https://github.com/g-plane/malva) into `deno
fmt`, which introduces the ability to format CSS, SCSS, Sass and Less
files.
On Linux x64 6.10, this PR increases about 800KiB:
```
❯ wc -c target/release/deno
125168728 target/release/deno
❯ wc -c target/release/deno
124349456 target/release/deno
```
This commit adds "--serve" flag to "deno init" subcommand,
that provides a template for quick starting a project using
"deno serve".
---------
Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
This PR updates `deno run` to fallback to executing tasks when there is
no script with the specified name. If there are both script and a task
with the same name then `deno run` will prioritise executing the script.
This moves YAML formatting behind an unstable flag for Deno 1.46. This
will make it opt-in to start and then we can remove the flag to make it
on by default in version of Deno after that.
This can be specified by doing `deno fmt --unstable-yaml` or by
specifying the following in a deno.json file:
```json
{
"unstable": ["fmt-yaml"]
}
```
Uses [sui](https://github.com/littledivy/sui) to inject metadata as a
custom section in the denort binary.
Metadata is stored as a Mach-O segment on macOS and PE `RT_RCDATA`
resource on Windows.
Fixes #11154
Fixes https://github.com/denoland/deno/issues/17753
```cpp
deno compile app.tsx
# on macOS
codesign --sign - ./app
# on Windows
signtool sign /fd SHA256 .\app.exe
```
---------
Signed-off-by: Divy Srivastava <dj.srivastava23@gmail.com>
Two small changes:
- In our BYONM errors, suggest running `deno install` instead of `npm
install` if `DENO_FUTURE` is set
- Only emit warning about `deno install` changes if you do `deno install
<foo>` with deno_future unset
```
> deno upgrade
error: Unsupported lockfile version 'invalid'. Try upgrading Deno or recreating the lockfile.
V:\scratch
> V:\deno\target\debug\deno upgrade
Looking up latest version
Local deno version 1.45.3 is the most recent release
```
Closes #24517
Closes #20729
This is in preparation for extracting out node resolution code from
ext/node (which is something I'm going to do gradually over time).
Uses https://github.com/denoland/deno_package_json
Originally landed in
f6fd6619e7.
Reverted in https://github.com/denoland/deno/pull/24574.
This reland contains a fix that sends "Accept: */*" header for calls made
from "FileFetcher". Absence of this header made downloading source code
from JSR broken. This is tested by ensuring this header is present in the
test server that servers JSR packages.
---------
Co-authored-by: Sean McArthur <sean@seanmonstar.com>
This makes bare specifiers for npm packages work when inside a
workspace, which emulates the same behaviour as when there's a
node_modules directory. The bare specifier can be overwritten by
specifying an import map entry or package.json dependency entry.
* https://github.com/denoland/deno_config/pull/88
Closes #24605
This commit re-implements `ext/fetch` and all dependent crates
using `hyper` and `hyper-util`, instead of `reqwest`.
The reasoning is that we want to have greater control and access
to low level `hyper` APIs when implementing `fetch` API as well
as `node:http` module.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit fixes memory leak described in
https://github.com/denoland/deno/issues/24380.
This is done by upgrading following crates:
- deno_ast
- deno_graph
- eszip
- dprint-plugin-typescript
- deno_lint
- deno_doc
- deno_emit
Adds support for running npm package lifecycle scripts, opted into via a
new `--allow-scripts` flag.
With this PR, when running `deno cache` (or `DENO_FUTURE=1 deno
install`) you can specify the `--allow-scripts=pkg1,pkg2` flag to run
lifecycle scripts attached to the given packages.
Note at the moment this only works when `nodeModulesDir` is true (using
the local resolver).
When a package with un-run lifecycle scripts is encountered, we emit a
warning suggesting things may not work and to try running lifecycle
scripts. Additionally, if a package script implicitly requires
`node-gyp` and it's not found on the system, we emit a warning.
Extra things in this PR:
- Extracted out bits of `task.rs` into a separate module for reuse
- Added a couple fields to `process.config` in order to support
`node-gyp` (it relies on a few variables being there)
- Drive by fix to downloading new npm packages to test registry
---
TODO:
- [x] validation for allow-scripts args (make sure it looks like an npm
package)
- [x] make allow-scripts matching smarter
- [ ] figure out what issues this closes
---
Review notes:
- This adds a bunch of deps to our test registry due to using
`node-gyp`, so it's pretty noisy
This commit deprecates `deno vendor` subcommand in favor
of using `--vendor` flag or `"vendor": true` setting in the config file.
The subcommand is still available (until Deno 2) but is hidden from
the help output.
Closes #20584
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
The `jest` test runner popularized putting tests into a `__tests__`
folder. Whilst many have switched to going with a `.test` suffix in the
file name these days, there are still many jest projects that have
`__tests__`. By adding this to the default test detection logic it makes
`deno test` discover those out of the box.
Closes: https://github.com/denoland/deno/issues/22633
This commit adds support for `confirm` and `prompt` APIs,
that instead of reading from stdin are using notebook frontend
to show modal boxes and wait for answers.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Adds much better support for the unstable Deno workspaces as well as
support for npm workspaces. npm workspaces is still lacking in that we
only install packages into the root node_modules folder. We'll make it
smarter over time in order for it to figure out when to add node_modules
folders within packages.
This includes a breaking change in config file resolution where we stop
searching for config files on the first found package.json unless it's
in a workspace. For the previous behaviour, the root deno.json needs to
be updated to be a workspace by adding `"workspace":
["./path-to-pkg-json-folder-goes-here"]`. See details in
https://github.com/denoland/deno_config/pull/66
Closes #24340
Closes #24159
Closes #24161
Closes #22020
Closes #18546
Closes #16106
Closes #24160
Closes #18296.
Adds a `--frozen` (alias `--frozen-lockfile`) flag that errors out if
the lockfile is out of date. This is useful for running in CI (where an
out of date lockfile is usually a mistake) or to prevent accidental
changes in dependencies.
As suggested in
https://github.com/denoland/deno/pull/24355#discussion_r1657875422.
I wasn't able to hide the mutex stuff as much as I'd like (ended up just
adding an escape hatch `inner()` method that locks the inner mutex),
because you can't return references to the inner fields through a mutex.
This is mostly motivated by the frozen lockfile changes
Fixes #22050.
It seems very unlikely that a user would be intending to enable deno's
internal debug logs by setting the DEBUG env var. If they really want
that, they can set `RUST_LOG=debug` instead.
Also removes permissions being passed in for node resolution. It was
completely useless because we only checked it for reading package.json
files, but Deno reading package.json files for resolution is perfectly
fine.
My guess is this is also a perf improvement because Deno is doing less
work.
Brings in:
* More fully typed structures (for when we get to implementing more)
* `with_metadata`, `with_buffers`, etc. from
https://github.com/runtimed/runtimed/pull/99
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
In https://github.com/denoland/deno/pull/23955 we changed the sqlite db
journal mode to WAL. This causes issues when someone is running an old
version of Deno using TRUNCATE and a new version because the two fight
against each other.
# Summary
This PR resolves about the issue.
fixes #10810
And the formerly context is in the PR.
#22582
Here is an expected behaviour example with this change.
- 🦕.test.ts
```ts
import { assertEquals } from "https://deno.land/std@0.215.0/assert/mod.ts";
Deno.test("example test", () => {
assertEquals("🍋", "🦕");
});
```
This commit adds initial support for ".npmrc" files.
Currently we only discover ".npmrc" files next to "package.json" files
and discovering these files in user home dir is left for a follow up.
This pass supports "_authToken" and "_auth" configuration
for providing authentication.
LSP support has been left for a follow up PR.
Towards https://github.com/denoland/deno/issues/16105
Fixes #23571.
Previously, we required a `deno.json` to be present (or the `--lock`
flag) in order for us to resolve a `deno.lock` file. This meant that if
you were using deno in an npm-first project deno wouldn't use a
lockfile.
Additionally, while I was fixing that, I discovered there were a couple
bugs keeping the future `install` command from using a lockfile.
With this PR, `install` will actually resolve the lockfile (or create
one if not present), and update it if it's not up-to-date. This also
speeds up `deno install`, as we can use the lockfile to skip work during
npm resolution.
This PR removes the use of the custom `utc_now` function in favor of the
`chrono` implementation. It resolves #22864.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
By default, uses a 60 second timeout, backing off 2x each time (can be
overridden using the hidden `DENO_SLOW_TEST_TIMEOUT` which we implement
only really for spec testing.
```
Deno.test(async function test() {
await new Promise(r => setTimeout(r, 130_000));
});
```
```
$ target/debug/deno test /tmp/test_slow.ts
Check file:///tmp/test_slow.ts
running 1 test from ../../../../../../tmp/test_slow.ts
test ...'test' is running very slowly (1m0s)
'test' is running very slowly (2m0s)
ok (2m10s)
ok | 1 passed | 0 failed (2m10s)
```
---------
Signed-off-by: Matt Mastracci <matthew@mastracci.com>
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This brings in [`runtimelib`](https://github.com/runtimed/runtimed) to
use:
## Fully typed structs for Jupyter Messages
```rust
let msg = connection.read().await?;
self
.send_iopub(
runtimelib::Status::busy().as_child_of(msg),
)
.await?;
```
## Jupyter paths
Jupyter paths are implemented in Rust, allowing the Deno kernel to be
installed completely via Deno without a requirement on Python or
Jupyter. Deno users will be able to install and use the kernel with just
VS Code or other editors that support Jupyter.
```rust
pub fn status() -> Result<(), AnyError> {
let user_data_dir = user_data_dir()?;
let kernel_spec_dir_path = user_data_dir.join("kernels").join("deno");
let kernel_spec_path = kernel_spec_dir_path.join("kernel.json");
if kernel_spec_path.exists() {
log::info!("✅ Deno kernel already installed");
Ok(())
} else {
log::warn!("ℹ️ Deno kernel is not yet installed, run `deno jupyter --install` to set it up");
Ok(())
}
}
```
Closes https://github.com/denoland/deno/issues/21619
Construct a new module graph container for workers instead of sharing it
with the main worker.
Fixes #17248
Fixes #23461
---------
Co-authored-by: David Sherret <dsherret@gmail.com>
This PR directly addresses the issue raised in #23282 where Deno panics
if `deno coverage` is called with `--include` regex that returns no
matches.
I've opted not to change the return value of `collect_summary` for
simplicity and return an empty `HashMap` instead
1. Generally we should prefer to use the `log` crate.
2. I very often accidentally commit `eprintln`s.
When we should use `println` or `eprintln`, it's not too bad to be a bit
more verbose and ignore the lint rule.
This PR implements the changes we plan to make to `deno install` in deno
2.0.
- `deno install` without arguments caches dependencies from
`package.json` / `deno.json` and sets up the `node_modules` folder
- `deno install <pkg>` adds the package to the config file (either
`package.json` or `deno.json`), i.e. it aliases `deno add`
- `deno add` can also add deps to `package.json` (this is gated behind
`DENO_FUTURE` due to uncertainty around handling projects with both
`deno.json` and `package.json`)
- `deno install -g <bin>` installs a package as a globally available
binary (the same as `deno install <bin>` in 1.0)
---------
Co-authored-by: Nathan Whitaker <nathan@deno.com>
By default, `deno serve` will assign port 8000 (like `Deno.serve`).
Users may choose a different port using `--port`.
`deno serve /tmp/file.ts`
`server.ts`:
```ts
export default {
fetch(req) {
return new Response("hello world!\n");
},
};
```
This PR enables V8 code cache for ES modules and for `require` scripts
through `op_eval_context`. Code cache artifacts are transparently stored
and fetched using sqlite db and are passed to V8. `--no-code-cache` can
be used to disable.
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
`TestEventSender` should not be Clone so we don't end up with multiple
copies of the same writer FD. This is probably not the cause of the test
channel lockups, but it's a lot easier to reason about.
Due to a terminating NUL that was placed in a `r#` string, we were not
actually NUL-terminating pipe names on Windows. While this has no
security implications due to the random nature of the prefix, it would
occasionally cause random failures when the trailing garbage would make
the pipe name invalid.
This commit moves logic of dispatching lifecycle events (
"load", "beforeunload", "unload") to be triggered from Rust.
Before that we were executing scripts from Rust, but now we
are storing references to functions from "99_main.js" and calling
them directly.
Prerequisite for https://github.com/denoland/deno/issues/23342
This is PR a smaller retry of #23066 that simply ensures all async
`ext/fs` ops are accounted for if left hanging in tests. This also sorts
the `OP_DETAILS` in alphabetical order for easy future reading.
When reviewing, it might be best to look at the commits in order for
better understanding.
The tests would deadlock if we tried to write the sync marker into a
pipe that was full because one test streamed just enough data to fill
the pipe, so when we went to actually write the sync marker we blocked
when nobody was reading.
We use a two-phase lock for sync markers now: one to indicate "ready to
sync" and the second to indicate that the sync bytes have been received.
This commit adds enum to "InstallFlags" and "UninstallFlags" that will
allow to support both local and global (un)installation.
Currently the local variant is not used.
Towards https://github.com/denoland/deno/issues/23062
Unused locals and parameters don't make sense to surface in remote
modules. Additionally, fast check can cause these kind of diagnostics
when publishing, so they should be ignored.
Closes #22959
In preparation for upcoming changes to `deno install` in Deno 2.
If `-g` or `--global` flag is not provided a warning will be emitted:
```
⚠️ `deno install` behavior will change in Deno 2. To preserve the current behavior use `-g` or `--global` flag.
```
The same will happen for `deno uninstall` - unless `-g`/`--global` flag
is provided
a warning will be emitted.
Towards https://github.com/denoland/deno/issues/23062
---------
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
This commit changes "deno init" subcommand to use "jsr:" specifier for
standard library "assert" module. It is unversioned, but we will change
it to `@^1` once `@std/assert` release version 1.0.
This allows us to start decoupling `deno` and `deno_std` release. The
release scripts have been updated to take that into account.
