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>
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.
This commit improves error messages for unstable APIs:
- `--unstable-broadcast-channel`
- `--unstable-cron`
- `--unstable-http`
- `--unstable-kv`
- `--unstable-temporal`
By providing information and hints what went wrong and how the
error can be fixed. It reuses the same infra that was added in
https://github.com/denoland/deno/pull/21764.
This was initially added in #25399 in order to make transitioning over
from package.json to deno.json more easy, but it causes some problems
that are shown in the issue and it also means that the output of `deno
install` would have different resolution than `npm install`. Overall, I
think it's too much complexity to be smarter about this and it's
probably best to not do it. If someone needs an aliased folder then they
should keep using a package.json
Closes #25538
The long form "files" config has been flattened into the parent.
Old:
```json
{
"test": {
"files": {
"include": ["**/*.ts"],
"exclude": ["ignore.ts"]
}
}
}
```
New:
```json
{
"test": {
"include": ["**/*.ts"],
"exclude": ["ignore.ts"]
}
}
```
This was deprecated some time ago, but we're removing it now in Deno
2.0.
Closes #25415
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 `.parse()` calls in permission code are only making it more
confusing, verbosity
is encouraged and welcome in this code even at the cost of not being
concise.
Left a couple TODOs to not use `AnyError`.
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
```
$ cat exports_error.js
Object.defineProperty(exports, "__esModule", { value: true });
$ deno exports_error.js
error: Uncaught (in promise) ReferenceError: exports is not defined
Object.defineProperty(exports, "__esModule", { value: true });
^
at file:///exports_error.js:1:23
info: Deno doesn't support CommonJS modules without `.cjs` extension.
hint: Rewrite this module to ESM or change the file extension to `.cjs`.
```
This commit adds support for executing top-level `.cjs` files,
as well as import `.cjs` files from within npm packages.
This works only for `.cjs` files, the contents of sibling `package.json`
are not consulted for the `"type"` field.
Closes https://github.com/denoland/deno/issues/25384
---------
Signed-off-by: David Sherret <dsherret@users.noreply.github.com>
Co-authored-by: Luca Casonato <hello@lcas.dev>
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
The property names of the `exports` field in `deno.json` was never
validated. The `patternProperties` only validates values, whose property
name matches the regex. It doesn't validate the property names
themselves. That's what `propertyNames` is for.
Related https://github.com/denoland/deno/issues/25435
Running a file like:
```
import "@std/dotenv/load";
```
Without a mapping in `imports` field of `deno.json` or `dependencies` of
`package.json`
will now error out with a hint:
```
error: Relative import path "@std/dotenv/load" not prefixed with / or ./ or ../
hint: Try running `deno add @std/dotenv/load`
at [WILDCARD]bare_specifier_without_import/main.ts:1:8
```
Closes https://github.com/denoland/deno/issues/24699
---------
Co-authored-by: David Sherret <dsherret@users.noreply.github.com>
This allows using npm deps of jsr deps without having to add them to the
root package.json.
Works by taking the package requirement and scanning the
`node_modules/.deno` directory for the best matching package, so it
relies on deno's node_modules structure.
Additionally to make the transition from package.json to deno.json
easier, Deno now:
1. Installs npm deps in a deno.json at the same time as installing npm
deps from a package.json.
2. Uses the alias in the import map for `node_modules/<alias>` for
better package.json compatiblity.
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>
`--allow-run` even with an allow list has essentially been
`--allow-all`... this locks it down more.
1. Resolves allow list for `--allow-run=` on startup to an absolute
path, then uses these paths when evaluating if a command can execute.
Also, adds these paths to `--deny-write`
1. Resolves the environment (cwd and env vars) before evaluating
permissions and before executing a command. Then uses this environment
to evaluate the permissions and then evaluate the command.
Fixes https://github.com/denoland/deno/issues/25333.
We fall back to junctions if the error kind is `PermissionDenied` but
the std library actually sets the kind to `Uncategorized` if the symlink
fails due to insufficient privileges. This was causing the fallback to
not actually fall back in this case.
Remove `--allow-hrtime` and `--deny-hrtime`. We are doing this because
it is already possible to get access to high resolution timers through
workers and SharedArrayBuffer.
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit hides following unstable flags:
- `--unstable-ffi` (the API is now stable)
- `--unstable-webgpu` (this API is now stable)
- `--unstable-fs` (no more unstable APIs)
- `--unstable-byonm` (BYONM is on by default)
The flags are still parseable, but they are not used. Concrete cleanup
will be done in a follow up PR.
This significantly simplifies the types for `Deno.serve`.
The following types become generic over the address type:
- ServeHandlerInfo
- ServeHandler
- ServeOptions
- ServeInit
The following types are removed entirely:
- ServeTlsOptions
- ServeUnixOptions
- ServeUnixHandlerInfo
- ServeUnixHandler
Note: this is implemented on Deploy. However, according to @magurotuna,
a thin compatibility layer might be in the works that'd prevent
breakages for PRs such as this one.
Towards #22079
`deno bundle` now produces:
```
error: ⚠️ `deno bundle` was removed in Deno 2.
See the Deno 1.x to 2.x Migration Guide for migration instructions: https://docs.deno.com/runtime/manual/advanced/migrate_deprecations
```
`deno bundle --help` now produces:
```
⚠️ `deno bundle` was removed in Deno 2.
See the Deno 1.x to 2.x Migration Guide for migration instructions: https://docs.deno.com/runtime/manual/advanced/migrate_deprecations
Usage: deno bundle [OPTIONS]
Options:
-q, --quiet Suppress diagnostic output
--unstable Enable all unstable features and APIs. Instead of using this flag, consider enabling individual unstable features
To view the list of individual unstable feature flags, run this command again with --help=unstable
```
Before:
```
$ deno upgrade v1.xx
error: Invalid version passed
```
After:
```
$ deno upgrade v1.xx
error: Invalid version passed (v1.xx)
Example usage:
deno upgrade | deno upgrade 1.46 | deno upgrade canary
```
Also updates help text to use "shorthand version" without flags, but a
positional arg.
This commit effectively turns Deno into Deno 2.0.
This is done by forcing `DENO_FUTURE=1` env var, that was available in
the past few months to try Deno 2 changes.
This commit contains several breaking changes scheduled for Deno 2:
- all deprecated JavaScript APIs are not available any more, mostly
`Deno.*` APIs
- `window` global is removed
- FFI, WebGPU and FS APIs are now stable and don't require
`--unstable-*` flags
- import assertions are no longer supported
- "bring your own node modules" is enabled by default
This is the first commit in a series that are scheduled before the Deno
2 release.
Follow up work is tracked in
https://github.com/denoland/deno/issues/25241.
---------
Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
Co-authored-by: Nayeem Rahman <nayeemrmn99@gmail.com>
Co-authored-by: Nathan Whitaker <nathan@deno.com>
In addition to printing a blog post information (if it's available),
this will also print a link to migration guide and the bug tracker.
---------
Signed-off-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
Fixes an incredibly obscure bug that causes parcel's file watcher to not
get any file update notifications on macOS.
The issue was that the native addon was calling `napi_resolve_deferred`,
but when we resolved the promise, v8 was running microtasks
automatically. That executed JS, which called back into the native addon
and broke the addon's assumption that the call wouldn't be reentrant.
Stores normalized version constraints in the lockfile, which will
improve reproducibility and will fix a bug with duplicate specifiers
ending up in the lockfile. Also, gets rid of some duplicate data in the
specifiers area of the lockfile.
Unlike in dprint, `single_quote` option is shared between all
formatters, so we shouldn't change this option when formatting
attributes in components. This PR fixes this.
This problem doesn't affect formatting HTML.
This commit remove `--lock-write` that was deprecated in v1.45 release.
Closes https://github.com/denoland/deno/issues/24167.
---------
Co-authored-by: Asher Gomez <ashersaupingomez@gmail.com>
Closes #25210 .
Removed --unstable-http from being displayed on deno run --help=unstable
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
Fix task names containing a colon not being found with `deno run`. We
were only checking for a `module not found` error message, but strings
containing a colon throw a different error.
Fixes https://github.com/denoland/deno/issues/25232
This commit enables the `log` feature for the `tracing` crate.
This allows us to examine additional detailed logs emitted by third party crates
that use `tracing` crate for logging by setting `RUST_LOG` env var or passing
`-L` option in command line.
Closes #25045
Fixes #24607.
This PR makes the logic that caches top level dependencies (things
present in import map) smarter, so we handle JSR dependencies without
root exports.
- rewrite flag help
- use gray for indentation
- reorganize permission flags and split them up
- make help subcommand act like help flag
- `deno run` outputs list of tasks
- Fixes #25120
error handling for `deno run` in case of no config file being found
needs to be improved
---------
Co-authored-by: Bartek Iwańczuk <biwanczuk@gmail.com>
This commit deprecates "import assertions" proposal that has been
replaced with "import attributes".
Any time an import assertion is encountered a warning will be printed
to the terminal. This warning will be printed for both local and
remote files (ie. user code and dependencies).
Import assertions support will be removed in Deno 2.
This commit changes `deno upgrade` subcommand to accept
a positional argument that can be either a version, release channel
name or a git hash, making invocations of `deno upgrade` much
more concise:
```
# before
$ deno upgrade --version 1.46.0
# after
$ deno upgrade 1.46.0
```
```
# before
$ deno upgrade --canary
# after
$ deno upgrade canary
```
```
# specific canary version before
$ deno upgrade --canary --version f042c39180
# after
$ deno upgrade f042c39180
```
Old flags are still supported, but hidden from the help output.
- Update ffi turbocall to use revised fast call api
- Remove `v8_version` function calls
- `*mut OwnedIsolate` is no longer stored in OpCtx gotham store
Permission flags are unified in a clearer and concise output.
Unstable flags are hidden by default with exception of the `unstable`
flag itself. the remaining unstable flags can be seen with a
`--help=unstable`.
This also cleans up to show unstable flags only for subcommands that
actually need them.
Also sorts flags alphabetically, and gorups various flags together in a
set of categories.
---------
Co-authored-by: crowlkats <crowlkats@toaxl.com>
This commit fixes computation of the latest available version
by taking into account which release channel the current
binary is on.
Before this commit, if user was on "RC" channel, calling
`deno upgrade` would not switch back to the "stable"
channel.
This commits add a CI script that allows to promote a certain
canary build to a "Release Candidate" release.
This is done using `libsui` and `patchver` utilities.
This change improves the Node.js compatibility in managed npm resolution
mode by disabling the discovery of `node_modules` when the
main specifier is inside of `DENO_DIR`.
closes #22732
closes #24589
This commit rewrites the internal `version` module that exported
various information about the current executable. Instead of exporting
several consts, we are now exporting a single const structure that
contains all the necessary information.
This is the first step towards cleaning up how we use this information
and should allow us to use SUI to be able to patch this information
in already produced binary making it easier to cut new releases.
---------
Co-authored-by: Divy Srivastava <dj.srivastava23@gmail.com>
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
```
