fix(tracing): drop the channel name type argument - #28
Open
gerardp wants to merge 2 commits into
Open
Conversation
Copy link
Copy Markdown
Sorry, something went wrong.
diagnostics_channel.tracingChannel received the channel name as its first type argument. That matched @types/node v25, where the first parameter was the unconstrained StoreType, but v26 swapped the two parameters and constrains the first one to object, so a string literal no longer fits and the published declarations stop compiling for consumers on v26. The name is a runtime value. Passing only the message type resolves to the same TracingChannel pair on both major versions.
Keeps the repository from regressing on the tracingChannel signature change, which the previous ^25.9.4 pin hid from CI.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #25.
Problem
src/tracing_channels.ts passed the channel name as the first type argument to
diagnostics_channel.tracingChannel. That matched @types/node v25, where the first parameter
was the unconstrained StoreType. In v26 the two parameters were swapped and the first one is
constrained to object:
So a string literal no longer fits, and the published declarations of @boringnode/queue fail to
compile for any consumer on @types/node v26.
Change
The channel name is a runtime value, so the name type argument goes away and the message type
becomes the sole argument. On v25 it binds to StoreType and ContextType defaults from it; on
v26 it binds to ContextType and StoreType defaults from it. Both end up with the same pair:
The second commit widens the @types/node dev dependency to ^25.9.4 || ^26.0.0 so CI
typechecks against the major that exposed this — the previous pin could not resolve to v26, which
is why the repository never saw it. yarn typecheck, yarn lint and yarn format are clean with
v26 resolved (the two oxlint warnings in src/otel.ts and tests/sync_adapter.spec.ts are
pre-existing on main). Drop that commit if you would rather bump the range separately — the
first commit stands on its own.
Verification
Repository typecheck, with the dev dependency resolved to @types/node@26.3.0:
Consumer side, using the reproduction from the issue — npm pack of this branch installed in a
clean project with typescript@7.0.2, knex@3.1.0 and import { Job } from '@boringnode/queue':
No runtime change: the channel names, the published messages and the subscriber contract are
identical.