fix(build): restore the react subpath types, and check the published paths - #171
Merged
Merged
Conversation
…paths 3.0.0 shipped `resortable/react` with no usable types. `package.json` pointed `exports["./react"].types`, and the matching `typesVersions` entry, at `dist/types/react/index.d.ts` — a file that release does not contain. The `vite-plugin-dts` major upgrade in the same release changed where declarations land, from `dist/types/` to mirroring `src/` at the dist root, and the manifest was never updated. TypeScript consumers get `TS7016: Could not find a declaration file for module 'resortable/react'`, so `useSortable` resolves to `any` and every property read off its events becomes a lint error in their own build. 2.3.0 is unaffected. Verified both ways by type-checking a consumer against each published tarball, under bundler, node16 and nodenext resolution. The declared paths now match what the build produces. Nothing here would have caught it. The unit and e2e suites run against `src/`, and bundle-size only weighs the bundles — the artifact users install is the one thing no job loads, which is how this shipped with CI fully green. `npm run check:exports` now verifies every path named by `main`, `module`, `unpkg`, `types`, `exports` and `typesVersions`, and runs in the build job. It fails on the exact 3.0.0 manifest. Also removes the `outDir: 'dist/types'` passed to `vite-plugin-dts` in both build configs: the current major ignores it, and the output is byte-identical without it. A config option that describes a layout the build does not produce is what made this hard to see. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_016znpWBRUXSTsHbJcKmVpN6
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
|
🎉 This PR is included in version 3.0.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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.
3.0.0 is broken for TypeScript consumers of
resortable/react. Found whena downstream app bumped to it and its lint job filled with
Unsafe member access ... on a type that cannot be resolved.What is wrong
package.jsonpointsexports["./react"].types— and the matchingtypesVersionsentry — atdist/types/react/index.d.ts. That file is not inthe 3.0.0 tarball. The
vite-plugin-dtsmajor upgrade in the dependency sweepthat went out with 3.0.0 changed where declarations land: they now mirror
src/at the dist root, so the file is atdist/react/index.d.ts. Themanifest still describes the old layout.
Reproduced by type-checking a two-line consumer against each published tarball:
TS7016: Could not find a declaration file for module 'resortable/react'.Confirmed under
bundler,node16andnodenextresolution. The main entryis unaffected; only the React subpath broke.
Downstream the symptom does not look like a packaging problem at all:
useSortableresolves toany, so every property read off its events trips@typescript-eslint/no-unsafe-member-accessand the consumer's lint jobfails, in their own source files, with no mention of resortable.
Why CI did not catch it
Nothing here loads the published artifact. The unit and e2e suites run against
src/,bundle-sizeonly weighs the bundles, andbuildonly checks that thebuild exits zero. The thing users actually install was the one thing no job
touched — which is how this shipped green.
npm run check:exportsnow verifies that every path named bymain,module,unpkg,types,exportsandtypesVersionsexists after a build, and runsin the
buildjob. Checked against the real 3.0.0 manifest, it fails with:Also
Both build configs passed
outDir: 'dist/types'tovite-plugin-dts. Thecurrent major ignores it — output is byte-identical with the option removed —
so it is gone, replaced by a note recording where declarations actually go. A
config option describing a layout the build does not produce is a large part of
why this was invisible.
Testing
npm run checkclean, 469 unit tests passing, and the consumer probe abovepasses against a tarball packed from this branch under all three resolution
modes.
This wants a patch release. Anything on 3.0.0 using the React adapter with
TypeScript is broken until then, and the fix is manifest-only — no API change.
🤖 Generated with Claude Code
https://claude.ai/code/session_016znpWBRUXSTsHbJcKmVpN6
🤖 Created with Claude Code · origin
interactive· 2026-09-03 19:36 UTC