-
Notifications
You must be signed in to change notification settings - Fork 236
chore: add typesVersion to core #5866
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🦋 Changeset detectedLatest commit: 0655d8d The changes in this PR will be included in the next version bump. This PR includes changesets to release 80 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📚 Branch Preview🔍 Visual Regression Test ResultsWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
Deployed to Azure Blob Storage: If the changes are expected, update the |
42cb9fe to
12ff023
Compare
Description
Adds
typesVersionsmapping to@spectrum-web-components/corepackage.json to improve TypeScript type resolution compatibility, particularly for users withmoduleResolution: "node"or older TypeScript versions.https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#version-selection-with-typesversions
Motivation and context
After the monorepo restructure in v1.10.0, some customers using
moduleResolution: "node"withskipLibCheck: falsereported TypeScript compilation errors when the type resolution chain passes through the core package.The
typesVersionsfield provides a fallback mechanism for TypeScript to locate declaration files when the standardexportsfield resolution encounters issues. This improves compatibility across different TypeScript configurations and versions.From my brief investigation,
typesVersionsworks because it provides explicit path mappings for TypeScript to find.d.tsfiles, works as a fallback whenexportsresolution is incomplete and supports older TypeScript versions that don't fully understandexportsfield. So this seems defensive enough.Author's checklist
Reviewer's checklist
patch,minor, ormajorfeaturesManual review test cases
Import and use SWC components (extend IconBase, use querySelector, etc.)
Expect: No TypeScript errors about missing HTMLElement or Element properties
Test with StackBlitz reproduction
Open the existing StackBlitz reproduction: https://stackblitz.com/edit/vitejs-vite-supsbswo?file=package.json,src%2Fmy-element.ts,tsconfig.json
Update dependencies to use this PR's changes (via snapshot or branch)
Run TypeScript type checking
Expect: TypeScript errors should be resolved