{{ message }}
fix: make the tsd type tests actually run - #322
Open
cryptodev-2s wants to merge 1 commit into
Open
Conversation
`yarn test:types` runs bare `tsd`, which finds no test files at all. It produces no output and exits 0 no matter what, so the 460 lines of type assertions in src/*.test-d.ts have not been checking anything. Proof: appending `expectAssignable<Hex>(999)` to hex.test-d.ts still exits 0. Pointing tsd at the files explicitly reports it correctly and exits 1. The cause is the `types` field. tsd resolves test files relative to it, and it has pointed at ./dist/index.d.cts since ts-bridge was adopted in #182 on 2024-04-23, which tsd 0.29 does not resolve. The `tsd.directory` setting does not compensate. There have been 26 releases since, all with this check silently passing. Fixing the invocation rather than the `types` field, since the latter is correct for consumers and only tsd is confused by it. All four existing files pass once actually executed, so nothing needed changing in them.
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.

Top of stack #315, on #321.
yarn test:typesruns baretsd, which finds no test files at all. It produces no output and exits 0 regardless, so the 460 lines of type assertions acrosssrc/*.test-d.tshave not been checking anything.Proof, before this change:
Pointing tsd at the files explicitly reports it properly and exits 1:
Cause
tsd resolves test files relative to the
typesfield, which has pointed at./dist/index.d.ctssince ts-bridge was adopted in #182 (2024-04-23). tsd 0.29 does not resolve.d.cts, and thetsd.directorysetting does not compensate. 26 releases have shipped since, all with this check silently passing.Fix
Fixing the invocation rather than the
typesfield, since the field is correct for consumers and only tsd is confused by it.All four files pass once actually executed, so none of them needed changing.
yarn test:typesnow exits 1 on a bad assertion and 0 when clean.Relevance to the migration
This was found while working out what to do with tsd in Phase B, since core has no way to run it. Worth knowing the honest baseline before deciding: these assertions have been dormant for 17 months, so whatever we do with them in core, we are not losing coverage we currently have.
Note
Low Risk
Only changes how the dev
test:typesscript invokes tsd; no runtime or published API impact.Overview
yarn test:typeswas a no-op: baretsdnever picked up thesrc/*.test-d.tssuites (tsd resolves tests viatypes→./dist/index.d.cts, which tsd 0.29 does not handle), so the command exited 0 without running ~460 lines of type assertions.The script now invokes
tsd --files 'src/*.test-d.ts'so those declaration tests actually execute and fail CI on bad assertions, without changing the publishedtypesfield.Reviewed by Cursor Bugbot for commit 0458748. Bugbot is set up for automated code reviews on this repo. Configure here.