fix(babel): use caret to specify some package versions #9174
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
jtoar
force-pushed
the
ds-babel/use-caret
branch
from
6b427ee
to
7d1261e
Compare
jtoar
added a commit
that referenced
this pull request
Sep 15, 2023
the previous babel fix (#9144) to issues like #9156 and #9073 was only a temporary solution and didn't work for all users. after more thinking, i'm pretty sure that the root of the problem is that we pin the version of the babel packages we depend on. take a redwood app that was just created from `yarn create redwood-app`. most redwood projects request a specific version of a babel package. for example, for `@babel/core`, redwood packages say they want `7.22.17`. the redwood packages aren't the only ones that want `@babel/core`, but they use a caret when they ask for the version, like `^7.22.5` at the outset, yarn can usually make everyone happy with one version. but say a new version of `@babel/core` comes out, `7.22.19`. and then a user installs storybook, or some other package that depends on `@babel/core`. the problem is that yarn checks npm to see if there's a new version, and if there is, it updates the caret versions like `^7.22.5` to resolve to the new one. but all the redwood packages are insisting they want `7.22.17`, not `7.22.19`, so yarn has to keep both around and now, when it comes to hoisting, has a choice to make: which version of `@babel/core` is at `node_modules/@babel/core`? more packages are ok with `7.22.19` so it wins out, and `7.22.17` gets buried into the redwood package's node_modules. to figure out which babel packages need the caret, i relied on a combination of `yarn info -R --dependents ${packageName}`, `yarn why ${packageName}`, and `find ./node_modules -type d -path '*/${packageName}'`. the next steps for this are to get it into canary so i can confirm.
jtoar
added a commit
that referenced
this pull request
Sep 15, 2023
the previous babel fix (#9144) to issues like #9156 and #9073 was only a temporary solution and didn't work for all users. after more thinking, i'm pretty sure that the root of the problem is that we pin the version of the babel packages we depend on. take a redwood app that was just created from `yarn create redwood-app`. most redwood projects request a specific version of a babel package. for example, for `@babel/core`, redwood packages say they want `7.22.17`. the redwood packages aren't the only ones that want `@babel/core`, but they use a caret when they ask for the version, like `^7.22.5` at the outset, yarn can usually make everyone happy with one version. but say a new version of `@babel/core` comes out, `7.22.19`. and then a user installs storybook, or some other package that depends on `@babel/core`. the problem is that yarn checks npm to see if there's a new version, and if there is, it updates the caret versions like `^7.22.5` to resolve to the new one. but all the redwood packages are insisting they want `7.22.17`, not `7.22.19`, so yarn has to keep both around and now, when it comes to hoisting, has a choice to make: which version of `@babel/core` is at `node_modules/@babel/core`? more packages are ok with `7.22.19` so it wins out, and `7.22.17` gets buried into the redwood package's node_modules. to figure out which babel packages need the caret, i relied on a combination of `yarn info -R --dependents ${packageName}`, `yarn why ${packageName}`, and `find ./node_modules -type d -path '*/${packageName}'`. the next steps for this are to get it into canary so i can confirm.
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.
the previous babel fix (#9144) to issues like #9156 and #9073 was only a temporary solution and didn't work for all users. after more thinking, i'm pretty sure that the root of the problem is that we pin the version of the babel packages we depend on.
take a redwood app that was just created from
yarn create redwood-app. most redwood projects request a specific version of a babel package. for example, for@babel/core, redwood packages say they want7.22.17. the redwood packages aren't the only ones that want@babel/core, but they use a caret when they ask for the version, like^7.22.5at the outset, yarn can usually make everyone happy with one version. but say a new version of
@babel/corecomes out,7.22.19. and then a user installs storybook, or some other package that depends on@babel/core. the problem is that yarn checks npm to see if there's a new version, and if there is, it updates the caret versions like^7.22.5to resolve to the new one. but all the redwood packages are insisting they want7.22.17, not7.22.19, so yarn has to keep both around and now, when it comes to hoisting, has a choice to make: which version of@babel/coreis atnode_modules/@babel/core? more packages are ok with7.22.19so it wins out, and7.22.17gets buried into the redwood package's node_modules.to figure out which babel packages need the caret, i relied on a combination of
yarn info -R --dependents ${packageName},yarn why ${packageName}, andfind ./node_modules -type d -path '*/${packageName}'.the next steps for this are to get it into canary so i can confirm.