deno task test dirties deno.lock with Node type entries

[rauhryan]

Problem

Running the baseline test command on a clean checkout dirties deno.lock by adding Node type dependency entries.

Observed while preparing local implementation work:

git submodule update --init --recursive
make
deno task test
git diff -- deno.lock

deno task test passed, but deno.lock changed to add entries like:

+    "npm:@types/node@*": "24.2.0",
...
+    "@types/node@24.2.0": {
+      "dependencies": ["undici-types"]
+    },
...
+    "undici-types@7.10.0": {
+      ...
+    },

Expected

A normal local build/test pass should leave a clean working tree when no source files were changed.

Actual

The tests pass, but the lockfile is modified. This creates noise for contributors and makes it unclear whether the lockfile change should be committed.

Notes

This may be related to generated wasm.ts importing node:zlib, or to Deno 2.4's handling of Node type dependencies during type checking.

Possible fixes to investigate:

• intentionally refresh and commit the lockfile if these entries are expected;
• adjust the generated/imported Node type usage so tests do not mutate the lockfile;
• make the relevant task fail instead of silently updating the lockfile, if lockfile drift is unintended.

Environment where observed:

deno 2.4.5
Homebrew clang 22.1.2
macOS arm64

[jbolda]

Update to the latest deno. I believe some of that comes default out of the box so I imagine that is the discrepancy.