fix: unpin react types #9727
Merged
fix: unpin react types #9727
Conversation
This file contains 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
jtoar
changed the title
|
This came up as a fix again the other day; this one should go out. See https://community.redwoodjs.com/t/you-must-register-a-usemutation-hook-via-the-graphglhooksprovider/5604/5. |
Tobbe
approved these changes
Feb 8, 2024
|
Testing locally, I think if I get a canary out with these new versions the errors here will go away. Going to try that; if it doesn't work I'll revert everything. So just bear with me for a bit here. |
jtoar
added a commit
that referenced
this pull request
Feb 9, 2024
Fixes https://community.redwoodjs.com/t/you-must-register-a-usemutation-hook-via-the-graphglhooksprovider/5604. This problem is very similar to the Babel issues we were seeing a few months ago or so. Dependencies that are used across the ecosystem are a poor choice for pinning because it results in node modules being hoisted in unpredictable ways. The current problem in the forum post is: - we pin dependencies that our framework packages also use like `@types/react` in a CRWA - we upgrade `@types/react` in the framework packages, but CRWA apps don't get upgraded and still request an older version - node module nesting ensues because yarn tries to make everyone happy, but has to do so via the node modules linker - the wrong node module gets required somehow because there's now two ways to find it (what the user in the forum was experiencing) Here's the difference in nesting before/after aligning the versions of `@types/react`: ``` % ls ./node_modules/@redwoodjs/testing/node_modules/ @apollo @redwoodjs @types pretty-format react-hot-toast @reach @testing-library ansi-styles react-helmet-async react-is % ls ./node_modules/@redwoodjs/testing/node_modules/ @types ``` What I did with Babel was use carets for packages that I found were prone to colliding with our other dependencies like Storybook. In this case we're kind of colliding with our own packages. Originally I wanted to remove the `@types/react-` packages from `@redwoodjs/testing`'s dependencies all together because CRWA projects ship with them in the web workspace now. But @Tobbe pointed out that the mailer on the api side uses React now, so removing them from `@redwoodjs/testing` without also adding them to the api workspace may be a bad idea. Then I realized many mailer packages have a peer dependency on React which isn't explicit provided by the api workspace. Then we started thinking about moving the react dependencies up to the root workspace to satisfy both sides, but I knew that the Docker api image focuses on the api workspace to keep the number of dependencies installed down. TL;DR this opened a can of worms I'm not ready to commit to so I settled on just carets all around for now. --------- Co-authored-by: Dominic Saadi <dominiceliassaadi@gmail.com>
jtoar
pushed a commit
that referenced
this pull request
Feb 9, 2024
dac09
added a commit
to dac09/redwood
that referenced
this pull request
Feb 9, 2024
…d-cookies-dbauth * 'main' of github.com:redwoodjs/redwood: chore: update rsc fixture (redwoodjs#9986) fix(server): use file extension in import, fix graphql route registering (redwoodjs#9984) chore(deps): update babel monorepo (redwoodjs#9983) fix: unpin react types (redwoodjs#9727) fix(docker): compose dev and prod (redwoodjs#9982) fix(deps): update prisma monorepo to v5.9.1 (redwoodjs#9980) fix(cli): use fetch instead of `yarn npm info` (redwoodjs#9975) fix(test): Update createServer test to use a different port to normal (redwoodjs#9977) fix(docker): corepack permissions fix and style updates (redwoodjs#9976)
jtoar
added a commit
that referenced
this pull request
Feb 16, 2024
…ndencies (#10020) Have been thinking about this one on and off for a while now and I don't think any of our packages should have the react types packages as dependencies if the web workspace in apps is going to have them. More generally, if a Redwood app is going to explicitly depend on a package that one of our framework packages also depends on, one of them should go or use the `'*'` specifier. I ran into an issue related to this a day or two ago with the deploy target CI providers. It was easily fixed if you knew what to look for. Unpinning them was a step forward cause yarn can sometimes make it work if you run dedupe or at worst edit or regenerate the lock file. But most people don't know what to look for and we shouldn't expect them to. The reason we didn't do this before (see the original comment in #9727) was that the mailer depends on the react types packages but doesn't explicitly list them as dependencies. Well, it can still get the react types packages implicitly from node_modules anyway cause the web workspace puts them there.
jtoar
added a commit
that referenced
this pull request
Feb 16, 2024
…ndencies (#10020) Have been thinking about this one on and off for a while now and I don't think any of our packages should have the react types packages as dependencies if the web workspace in apps is going to have them. More generally, if a Redwood app is going to explicitly depend on a package that one of our framework packages also depends on, one of them should go or use the `'*'` specifier. I ran into an issue related to this a day or two ago with the deploy target CI providers. It was easily fixed if you knew what to look for. Unpinning them was a step forward cause yarn can sometimes make it work if you run dedupe or at worst edit or regenerate the lock file. But most people don't know what to look for and we shouldn't expect them to. The reason we didn't do this before (see the original comment in #9727) was that the mailer depends on the react types packages but doesn't explicitly list them as dependencies. Well, it can still get the react types packages implicitly from node_modules anyway cause the web workspace puts them there.
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.
Fixes https://community.redwoodjs.com/t/you-must-register-a-usemutation-hook-via-the-graphglhooksprovider/5604. This problem is very similar to the Babel issues we were seeing a few months ago or so.
Dependencies that are used across the ecosystem are a poor choice for pinning because it results in node modules being hoisted in unpredictable ways.
The current problem in the forum post is:
@types/reactin a CRWA@types/reactin the framework packages, but CRWA apps don't get upgraded and still request an older versionHere's the difference in nesting before/after aligning the versions of
@types/react:What I did with Babel was use carets for packages that I found were prone to colliding with our other dependencies like Storybook. In this case we're kind of colliding with our own packages.
Originally I wanted to remove the
@types/react-packages from@redwoodjs/testing's dependencies all together because CRWA projects ship with them in the web workspace now. But @Tobbe pointed out that the mailer on the api side uses React now, so removing them from@redwoodjs/testingwithout also adding them to the api workspace may be a bad idea. Then I realized many mailer packages have a peer dependency on React which isn't explicit provided by the api workspace. Then we started thinking about moving the react dependencies up to the root workspace to satisfy both sides, but I knew that the Docker api image focuses on the api workspace to keep the number of dependencies installed down. TL;DR this opened a can of worms I'm not ready to commit to so I settled on just carets all around for now.