denoland
Deno not respecting symlinks when updating deno.lock
deno --version
deno 2.1.10 (stable, release, x86_64-unknown-linux-gnu)
v8 13.0.245.12-rusty
typescript 5.6.2
Hello, complete deno noob here, so I might be missing something major. That being said: I have an overly-complicated docker setup for local development, which involves symlinking both package.json (sadly couldn't get deno.json to work with svelte on my setup) and deno.lock into the project directory -- ie, the deno project contains the link, and NOT the target!
/project$ ls -l
# ...
-rw-r----- 1 root root 25868 Feb 17 16:43 deno.lock -> /artifacts/deno.lock
# ...
lrwxrwxrwx 1 root root 38 Feb 17 16:16 package.json -> /artifacts/package.json
# ...
When I run an operation that updates the lockfile, for example, deno add npm:vitest --dev, package.json is (correctly, IMO) updated without overwriting the symlink. However, deno.lock gets overwritten entirely, destroying the symlink:
/project$ deno add npm:vitest --dev
/project$ ls -l
# ...
-rw-r----- 1 deno_app deno 25868 Feb 17 16:45 deno.lock
# ...
lrwxrwxrwx 1 root root 38 Feb 17 16:45 package.json -> /artifacts/package.json
# ...
IMO, updating the lockfile should follow the symlink before updating, especially since that's what updates to package.json do.
Unfortunately, I also can't work around this by using a hardlink, because the "real" lockfile is located on a docker volume, whereas the project directory is within the container's filesystem.
This may just be an unsupported scenario. We don't canonicalize the paths of anything in Deno for performance reasons (only node_modules folders gets canonicalized because that's required for node resolution) and changing that might be considered a breaking change.
I'm struggling with related problems. For a situation like @Badg described, maybe setting "lock": "/artifacts/deno.lock" in the deno.json file would work? For my build setup, it seems to be a viable alternative to the symlink.
