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.
This commits stabilizes CSS, HTML and YAML formatters
in `deno fmt`.
It is no longer required to use either of these flags:
- `--unstable-css`
- `--unstable-html`
- `--unstable-yaml`
Or these `unstable` options in the config file:
- `fmt-css`
- `fmt-html`
- `html-yaml`
This commit adds better handling for terminal errors when
`window` global is used. This global is removed in Deno 2,
and while we have lints to help with that, an information and
hints are helpful to guide users to working code.
Ref https://github.com/denoland/deno/issues/25797
Fixes https://github.com/denoland/deno/issues/23508
`width` and `height` are required to configure the wgpu surface because
Deno is headless and depends on user to create a window. The options
were non-standard extension of `GPUCanvasConfiguration#configure`.
This PR adds a required options parameter with the `width` and `height`
options to `Deno.UnsafeWindowSurface` constructor.
```typescript
// Old, non-standard extension of GPUCanvasConfiguration
const surface = new Deno.UnsafeWindowSurface("x11", displayHandle, windowHandle);
const context = surface.getContext();
context.configure({ width: 600, height: 800, /* ... */ });
```
```typescript
// New
const surface = new Deno.UnsafeWindowSurface({
system: "x11",
windowHandle,
displayHandle,
width: 600,
height: 800,
});
const context = surface.getContext();
context.configure({ /* ... */ });
```
Fixes a regression where we were ignoring `--node-modules-dir` if there
was no value passed with it. We should instead default to "auto", to
maintain compat with deno 1
Fixes rsbuild running in deno.
You can look at the test to see what was failing, the gist is that we
were trying to statically analyze the re-exports of a CJS script, and if
we couldn't find the source for the re-exported file we would fail.
Instead, we should just treat these as if they were too dynamic to
analyze, and let it fail (or succeed) at runtime. This aligns with
node's behavior.
This commit fixes issues with the pseudo test file generation logic,
namely:
- `export`s declared in snippets
- auto import insertion for `default export`
## Case 1: `export`s declared in snippets
In the previous implementation, `export`s declared in snippets were
moved to the top level of the module in the generated pseudo test file.
This is required because `export` must be at the top level.
This becomes a problem if such a `export` has a body, containing a
reference to a local variable. Suppose we extract this snippet from
JSDoc:
```ts
const logger = createLogger("my-awesome-module");
export function sum(a: number, b: number): number {
logger.debug("sum called");
return a + b;
}
```
This gets converted into the following invalid code (note that `export
function sum` is moved to the top level, but its body references
`logger` variable which can't be referenced from here):
```ts
export function sum(a: number, b: number): number {
logger.debug("sum called");
return a + b;
}
Deno.test("./base.ts$1-7.ts", async () => {
const logger = createLogger("my-awesome-module");
});
```
To resolve this issue, this commit adds a logic to remove the `export`
keyword, allowing the exported items to stay in the `Deno.test` block
scope, like so:
```ts
Deno.test("./base.ts$1-7.ts", async () => {
const logger = createLogger("my-awesome-module");
function sum(a: number, b: number): number {
logger.debug("sum called");
return a + b;
}
});
```
## Case 2: default export
Previously `default export foo` was not captured by the export
collector, so auto import insertion didn't work for this case. To put it
concretely, the following code snippet didn't work when run with `deno
test --doc` because `import foo from "file:///path/to/mod.ts"` didn't
get inserted automatically:
```ts
/**
* ```ts
* console.log(foo);
* ```
*
* @module
*/
const foo = 42;
export default foo;
```
This commit fixes this issue and the above example works fine.
---
Fixes #25718
This commit stabilizes the `fetch` function declaration for use with
`Deno.HttpClient` and moves it from `lib.deno.unstable.d.ts` to
`lib.deno.shared_globals.d.ts`.
`Deno.HttpClient` was stabilized in #25569, but the associated override
declaration for `fetch` is still marked as experimental. This should
also be stabilized now and moved to a different d.ts file.
This commit lets `deno test --doc` command actually evaluate code snippets in
JSDoc and markdown files.
## How it works
1. Extract code snippets from JSDoc or code fences
2. Convert them into pseudo files by wrapping them in `Deno.test(...)`
3. Register the pseudo files as in-memory files
4. Run type-check and evaluation
We apply some magic at the step 2 - let's say we have the following file named
`mod.ts` as an input:
````ts
/**
* ```ts
* import { assertEquals } from "jsr:@std/assert/equals";
*
* assertEquals(add(1, 2), 3);
* ```
*/
export function add(a: number, b: number) {
return a + b;
}
````
This is virtually transformed into:
```ts
import { assertEquals } from "jsr:@std/assert/equals";
import { add } from "files:///path/to/mod.ts";
Deno.test("mod.ts$2-7.ts", async () => {
assertEquals(add(1, 2), 3);
});
```
Note that a new import statement is inserted here to make `add` function
available. In a nutshell, all items exported from `mod.ts` become available in
the generated pseudo file with this automatic import insertion.
The intention behind this design is that, from library user's standpoint, it
should be very obvious that this `add` function is what this example code is
attached to. Also, if there is an explicit import statement like
`import { add } from "./mod.ts"`, this import path `./mod.ts` is not helpful for
doc readers because they will need to import it in a different way.
The automatic import insertion has some edge cases, in particular where there is
a local variable in a snippet with the same name as one of the exported items.
This case is addressed by employing swc's scope analysis (see test cases for
more details).
## "type-checking only" mode stays around
This change will likely impact a lot of existing doc tests in the ecosystem
because some doc tests rely on the fact that they are not evaluated - some cause
side effects if executed, some throw errors at runtime although they do pass the
type check, etc. To help those tests gradually transition to the ones runnable
with the new `deno test --doc`, we will keep providing the ability to run
type-checking only via `deno check --doc`. Additionally there is a `--doc-only`
option added to the `check` subcommand too, which is useful when you want to
type-check on code snippets in markdown files, as normal `deno check` command
doesn't accept markdown.
## Demo
https://github.com/user-attachments/assets/47e9af73-d16e-472d-b09e-1853b9e8f5ce
---
Closes #4716
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
```
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 changes how system certificates are loaded on startup.
Instead of hard erroring if a certificate can't be decoded, we are now
printing a warning and bumping a hex representation of the certificate
and continue execution.
Ref https://github.com/denoland/deno/issues/24137
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.
