Repository navigation
Fix misplaced @ts-expect-error in PreferencesModalTabs - #80181
giteshsarvaiya wants to merge 1 commit into
Conversation
The directive was suppressing the as prop line, but TypeScript now reports the overload mismatch on the Navigator.Button opening tag, leaving the error unsuppressed and breaking the TypeScript build.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @giteshsarvaiya! In case you missed it, we'd love to have you join us in our Slack community. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
github-actions
Bot
added
the
First-time Contributor
|
closing this as it was local issue, i was running the project with stale node_modules, running npm install fixed it. thanks to @Mamaduka for the quick sanity check on my query # core-editor |
1 participant
What
Moves a
@ts-expect-errorcomment inPreferencesModalTabsfrom above theas={ Item }prop to above the<Navigator.Button>opening tag.Why
@ts-expect-erroronly suppresses the diagnostic reported on the line immediately following it. Previously that was theas={ Item }line, which is where TypeScript used to report the overload mismatch for this JSX element.Two recent trunk changes shifted where TS attributes that error:
Item's underlying type.As a result, TS started reporting the error on the
<Navigator.Button>opening tag instead of theasprop line. The directive, still sitting aboveas, no longer suppressed anything (flagged as "unused"), while the real error surfaced one line up, unsuppressed — breaking thetsc --buildstep ofnpm run dev/npm run build.How
Moved the
@ts-expect-errorcomment from directly aboveas={ Item }to directly above the<Navigator.Button>opening tag, matching where TypeScript now attributes the diagnostic. The underlying type mismatch is unchanged and intentional (Item's props aren't currently compatible withNavigator.Button'sasprop typing) — this only relocates the suppression to where it's actually needed.