Node deprecation warning DEP0205 emitted on every frontend build #32

Open
opened 2026-08-09 03:49:12 +02:00 by clawbot · 0 comments
Collaborator

Problem

Every run of make check / make build emits a Node deprecation warning during the Vite build:

(node:2498178) [DEP0205] DeprecationWarning: `module.register()` is deprecated.
Use `module.registerHooks()` instead.
(Use `node --trace-deprecation ...` to show where the warning was created)

Observed independently during a make check run on main at fbfe1df, and again by the implementer of #14 during their verification.

The build succeeds and output is correct — this is noise today, not a failure. But deprecation warnings are action items, not noise: module.register() will eventually be removed, and when it is, the build breaks with no warning period left.

Diagnosis needed before any fix

The warning almost certainly originates inside Vite or one of its transitive dependencies rather than in this repo's own code — src/main.js, vite.config.js, and the script/ entrypoints contain no module.register() call. Confirm that before changing anything:

  • Re-run the build with --trace-deprecation to get the actual stack and identify which package calls it.
  • Check whether a newer Vite release already fixes it. package.json currently has vite: ^7.3.1.

If it is upstream and already fixed, the correct action is a dependency bump. If it is upstream and not yet fixed, the correct action is to record the finding here and close as "wait for upstream" — do not suppress the warning with NODE_OPTIONS=--no-deprecation or similar. Silencing it removes the only signal we will get before the removal lands.

Definition of done

One of these outcomes, with the reasoning written up on this issue:

  • Upstream fixed: dependency bumped, yarn.lock updated with integrity hashes intact, warning gone, make check and docker build . both pass.
  • Upstream not yet fixed: the responsible package and its upstream issue/PR are identified and linked here, and this issue stays open pending that release. No suppression, no workaround.
  • Ours after all: fixed at the call site in this repo.

In all cases:

  • The trace output identifying the caller is posted on this issue, so the next person does not have to rediscover it.
  • make check passes.
  • If any file changes, TODO.md is updated in the same commit and the commit title ends with (closes #N).

Implementation requirements

  • Deliberately not on the 1.0.0 milestone. It does not block a tag and the fix may not be in our hands.
  • Any dependency bump must keep yarn.lock fully hash-pinned — the lockfile currently has 100% integrity-hash coverage across all 119 resolved entries and that must not regress.
  • Use yarn, not npm.
  • make targets and script/ entrypoints only.
  • No attribution trailers in the commit message.
## Problem Every run of `make check` / `make build` emits a Node deprecation warning during the Vite build: ``` (node:2498178) [DEP0205] DeprecationWarning: `module.register()` is deprecated. Use `module.registerHooks()` instead. (Use `node --trace-deprecation ...` to show where the warning was created) ``` Observed independently during a `make check` run on `main` at `fbfe1df`, and again by the implementer of #14 during their verification. The build succeeds and output is correct — this is noise today, not a failure. But deprecation warnings are action items, not noise: `module.register()` will eventually be removed, and when it is, the build breaks with no warning period left. ## Diagnosis needed before any fix The warning almost certainly originates inside Vite or one of its transitive dependencies rather than in this repo's own code — `src/main.js`, `vite.config.js`, and the `script/` entrypoints contain no `module.register()` call. Confirm that before changing anything: - Re-run the build with `--trace-deprecation` to get the actual stack and identify which package calls it. - Check whether a newer Vite release already fixes it. `package.json` currently has `vite: ^7.3.1`. If it is upstream and already fixed, the correct action is a dependency bump. If it is upstream and not yet fixed, the correct action is to record the finding here and close as "wait for upstream" — do **not** suppress the warning with `NODE_OPTIONS=--no-deprecation` or similar. Silencing it removes the only signal we will get before the removal lands. ## Definition of done One of these outcomes, with the reasoning written up on this issue: - [ ] **Upstream fixed:** dependency bumped, `yarn.lock` updated with integrity hashes intact, warning gone, `make check` and `docker build .` both pass. - [ ] **Upstream not yet fixed:** the responsible package and its upstream issue/PR are identified and linked here, and this issue stays open pending that release. No suppression, no workaround. - [ ] **Ours after all:** fixed at the call site in this repo. In all cases: - [ ] The trace output identifying the caller is posted on this issue, so the next person does not have to rediscover it. - [ ] `make check` passes. - [ ] If any file changes, `TODO.md` is updated in the same commit and the commit title ends with ` (closes #N)`. ## Implementation requirements - Deliberately **not** on the `1.0.0` milestone. It does not block a tag and the fix may not be in our hands. - Any dependency bump must keep `yarn.lock` fully hash-pinned — the lockfile currently has 100% integrity-hash coverage across all 119 resolved entries and that must not regress. - Use `yarn`, not `npm`. - `make` targets and `script/` entrypoints only. - No attribution trailers in the commit message.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/netwatch#32