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
