5 of 6 standards met
Deno v2.7.2 on x86_64-unknown-linux-gnu. Platform: linux x86_64 Version: 2.7.2 Args: ["/opt/hostedtoolcache/deno/2.7.2/x64/deno", "run", "--unstable-kv", "-A", "dev.ts", "build"] Issue happens when building. Issue does not happen with 2.7.1. thread 'main' (2126) panicked at libs/npm/resolution/graph.rs:448:17: not found package id: @opentelemetry/core@2.6.0_@opentelemetry+api@1.9.0 A panic occurred in Deno. stack backtrace: View trace: here
Version: Deno 2.7.1 macOS 26.3 The following show that two copies of the binary are placed in , 94.8MB each. In theory the raw bytes may be deduplicated on the physical disk, but I don't want everyone with a local checkout to have a that shows up as 189.7MB larger when 95MB larger would do just as well. There are also various circumstances where the binaries might take up duplicate space on disk. This seems to be due to: https://github.com/denoland/deno/blob/2334e53e96613878baaeac8ae4847e84e7c2ec36/tools/release/npm/install_api.cjs#L45 I'm interested in testing against locally in CI for a complex project, but I don't think I'm comfortable doing so under these circumstances. Is there any reason the executable couldn't be symlinked instead of copied to the target path?
Repository: denoland/deno. Description: A modern runtime for JavaScript and TypeScript. Stars: 106272, Forks: 5908. Primary language: Rust. Languages: Rust (59.2%), TypeScript (29.6%), JavaScript (11.1%), CSS (0%), Nix (0%). License: MIT. Homepage: https://deno.com Topics: deno, javascript, rust, typescript. Latest release: v2.7.2 (14h ago). Open PRs: 100, open issues: 2420. Last activity: 7h ago. Community health: 100%. Top contributors: bartlomieju, dsherret, ry, littledivy, nayeemrmn, lucacasonato, kt3k, kitsonk, piscisaureus, crowlKats and others.
Rust
Last 12 weeks · 460 commits
As can be seen in the documentation, is meant to be the folder wherein Deno will install executables, with the default being . However, the current behaviour of the and commands, if is set, is to still append "bin" to the path. This leads to executables being installed in a folder like , which is obviously not the intended behaviour. This commit removes this appending. Do note that this is a breaking change in the behaviour of the flag, as previously it referred to a folder wherein the folder was located, but now it refers to the folder itself. For example: would previously install the executable in , but now it will install it in . This would also most certainly break many third-party tools that expect the current behaviour. See for example: https://github.com/jdx/mise/blob/0cea93b27bc46ba9219557532d6d1d061d05f81d/src/plugins/core/deno.rs#L144 https://github.com/asdf-community/asdf-deno/blob/13f7f08c93989fdc0b372e78df226e511fc13fa9/bin/exec-env#L7 Closes #26442 Please do note that, as I am currently on a family visit out of the country, I currently only have my poor little laptop. As such, I do not have the storage capacity to build the project or run the test suite, so THIS CODE IS UNTESTED. If someone else could test it for me, that'd be grand, and otherwise I'll do it when I'm back home in a couple of weeks.