-
Notifications
You must be signed in to change notification settings - Fork 851
Fix version conflicts for @types/react #24294
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
|
Caution: This PR has changes that must be merged to WordPress.com |
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available. Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped. Jetpack plugin:
|
I note we're still using react v17, not v18. Should the types package's version match the react version?
What impact would that have on build time? Could the actual build process report errors instead of having to run a separate build before the build? |
That may not make a huge difference in terms of types. The reason for my suggestion to use v18 is that there are already some underlying packages that already have v18 as a dependency. if you search for
Yes, just a little bit.
Yes, for that we need to wire up a TS checker plugin with webpack which won't be any different than |
I see only four. All are other
When you get around to trying it, let's be sure to quantify the impact. We might also try running tsc concurrently with the build instead of serially before it. Some quick searches suggest that the tsconfig should have options like noEmit or emitDeclarationOnly so tsc doesn't write files.
Yeah, now that I look I see babel just understands the syntax well enough to ignore it, it doesn't actually process the types. |
It's possible that more external packages will upgrade soon.
Oh yeah, running it in concurrently is a great idea. Thank you. |
Our We can add |
And when they do, will they also want react 18 so we'll have to wait on those updates anyway? That's why #24276 brought |
Yeah we can do that. So, what's the easiest way to keep |
For direct dependencies from our stuff, just don't do the upgrade. If we also need to worry about indirect deps of things, I suppose if we really needed to we could see about using the afterAllResolved hook in pnpmfile to throw an error if v18 is getting added. After first cleaning up the existing four deps pulling it in. |
Do we have an example of how to do that? I have no idea 😃 |
Not that I know of, we've never done it before. The whole JS ecosystem is designed for entirely the opposite use case, that dependencies can have their own copies of any deps they need instead of having to be locked to a particular shared version. |
|
@anomiex I have made the changes to use v17. |
renatoagds
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Working fine. LGTM
|
Great news! One last step: head over to your WordPress.com diff, D80354-code, and deploy it. Thank you! |
|
r245802-wpcom |
| // Override @types/react* dependencies in order to use their specific versions | ||
| for ( const dep of [ '@types/react', '@types/react-dom', '@types/react-test-renderer' ] ) { | ||
| if ( pkg.dependencies?.[ dep ] ) { | ||
| pkg.dependencies[ dep ] = '17.x'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just arbitrarily forcing every dep on these packages to "17.x" seems risky to me. But I guess we'll see what happens.
I was suggesting we avoid upgrading things that would bring in a 18.x dep rather than blindly overriding them.
Due to type conflict between v17 and v18 of
@types/react, we have some TypeScript errors in certain components. For example onmasterbranch, if you runcd projects/js-packages/components/ && pnpm tsc, you will see TS error(s).Changes proposed in this Pull Request:
@types/reactto v18Jetpack product discussion
See #24256 (comment) and #24276 (comment)
Does this pull request change what data or activity we track or use?
No
Testing instructions:
jetpack install --allorpnpm installcd projects/js-packages/components/ && pnpm tscNext Steps
I think it's the time to make TS check a part of the build process by simply running the TypeScript compiler CLI -
tscbefore running the actual build commands to avoid any errors being left in TS components.It will be as simple as adding a
"build": "tsc && ..."script tojs-packages/componentsandplugins/jetpacketc.Thoughts @Automattic/jetpack-agora ?