fix(tracing): drop the channel name type argument - #28
Open
gerardp wants to merge 2 commits into
Open
Conversation
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
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.tspassed the channel name as the first type argument todiagnostics_channel.tracingChannel. That matched@types/nodev25, where the first parameterwas the unconstrained
StoreType. In v26 the two parameters were swapped and the first one isconstrained to
object:So a string literal no longer fits, and the published declarations of
@boringnode/queuefail tocompile for any consumer on
@types/nodev26.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
StoreTypeandContextTypedefaults from it; onv26 it binds to
ContextTypeandStoreTypedefaults from it. Both end up with the same pair:The second commit widens the
@types/nodedev dependency to^25.9.4 || ^26.0.0so CItypechecks 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 lintandyarn formatare clean withv26 resolved (the two
oxlintwarnings insrc/otel.tsandtests/sync_adapter.spec.tsarepre-existing on
main). Drop that commit if you would rather bump the range separately — thefirst commit stands on its own.
Verification
Repository typecheck, with the dev dependency resolved to
@types/node@26.3.0:src/tracing_channels.tsyarn typecheckmaintests/otel.spec.ts, e.g.Argument of type 'JobExecuteMessage' is not assignable to parameter of type '"boringqueue.job.execute"'Consumer side, using the reproduction from the issue —
npm packof this branch installed in aclean project with
typescript@7.0.2,knex@3.1.0andimport { Job } from '@boringnode/queue':@types/node@25.9.4@types/node@26.3.00.7.1Type 'string' does not satisfy the constraint 'object'No runtime change: the channel names, the published messages and the subscriber contract are
identical.