-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Enable yarn 3 for Redwood projects #4444
Conversation
Note that I'm not sure if we should add yarn to the On the other hand, you do commit yarn now (we do it in the framework), so why not just do it from the start? Also I wanted to use corepack, but we still support node 14 so it's not viable yet. |
Another thing that's gonna be tricky is making sure users can still run the CLI from the web and api directories. |
@jtoar I'm happy with the pattern you're using here. It's understandable and manageable. I am very curious about feedback from the Yarn team, however. One step forward... Q1
^^ Oh, this gives me an idea — what if we set Thoughts? Q2
^^ Cause the CLI package will now need to be included in api/package.json and web/package.json. That's ok and expected. Q3
If it makes this work, I'm all for bumping the Node requirements to v16 for 1.0.0 GA. That's not unreasonable (or hard). We're asking devs to update development environment only — deploy targets will still be v14. Q4
To confirm, you are still planning to decouple CLI from Core, correct? If anything, we should rename Core --> Webpack and then include Webpack as a dependency in CLI. TBD with Peter and Danny when the time is right. |
aab3b8d
to
0716ebc
Compare
Corepack has been backported to v14 so you'd only need to bump it to v14.19.0 if that's the only requirement |
we're not using zero installs, and this isn't CI; see #4444 (comment)
we're not using zero installs, and this isn't CI; see #4444 (comment)
69f186d
to
571113a
Compare
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.
@jtoar Phenomenal work here, Dom. I had one question about setup ui chakra-ui, which I did test myself with Yarn 3 and setup completed successfully.
Let's hold merge until we discuss timing. Stoked to see this go in!
const tscForAllSides = sides.map((side) => { | ||
const projectDir = path.join(getPaths().base, side) | ||
// -s flag to suppress error output from yarn. For example yarn doc link on non-zero status. | ||
// Since it'll be printed anyways after the whole execution. | ||
return { | ||
cwd: projectDir, | ||
command: `yarn -s tsc --noEmit --skipLibCheck`, | ||
command: `yarn ${ |
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.
@jtoar what if we created a helper for running yarn commands so all the logic is in one place? Something like runYarnCommand
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.
This is such tremendous work @jtoar - I applaud your patience and thoroughness here!
Would you mind ✋ HODLING the PR - some of the minor comments are addressed/dismissed?
@jtoar I've tested Yarn 3 ✅ Yarn 1
Strange that it's a telemetry error, but I think that might be a herring. I tried |
@thedavidprice could you give me a little more info on how |
It failed on all the commands that was just the last one I tried. The failure was immediate. |
Before you implement yarn 3 in Redwood, I request you to go through this |
Hi @Ramandhingra Please see my reply on your forum thread.
Thanks! |
…rojects-to-yarn-3 * 'main' of github.com:redwoodjs/redwood: (29 commits) Update dependency eslint-config-prettier to v8.5.0 (#4631) Update dependency msw to v0.38.2 (#4630) Update dependency @clerk/types to v1.27.0 (#4628) Update dependency @clerk/clerk-js to v2.16.0 (#4627) Update dependency @types/react-dom to v17.0.13 (#4629) Update dependency @types/testing-library__jest-dom to v5.14.3 (#4624) Update dependency @types/aws-lambda to v8.10.93 (#4620) Webhook verifiers: Make them all support timestamp diff check (#4608) Add custom log payload support to logFormatter (#4619) Update dependency @types/react-dom to v17.0.12 (#4621) part II of #4623 (#4626) Update dependency systeminformation to v5.11.6 (#4611) Update dependency @clerk/clerk-js to v2.15.0 (#4606) remove Redwood extension from vscode rec (#4613) (fixture chore) pin fixture autoprefixer 9.8.8 (#4623) update yarn.lock v0.47.1 update yarn.lock fixi(prisma): Set default cwd for runCommand task to base (#4604) Update actions/checkout action to v3 (#4610) ...
…ors-db-auth * 'main' of github.com:redwoodjs/redwood: [WIP] Enable yarn 3 for Redwood projects (#4444) Update dependency eslint-config-prettier to v8.5.0 (#4631) Update dependency msw to v0.38.2 (#4630) Update dependency @clerk/types to v1.27.0 (#4628) Update dependency @clerk/clerk-js to v2.16.0 (#4627) Update dependency @types/react-dom to v17.0.13 (#4629) Update dependency @types/testing-library__jest-dom to v5.14.3 (#4624) Update dependency @types/aws-lambda to v8.10.93 (#4620) Webhook verifiers: Make them all support timestamp diff check (#4608) Add custom log payload support to logFormatter (#4619)
I've run through the 5 steps for upgrading to yarn 3 here and still seeing
Ended up resolving by going back to yarn v1
|
Hey @stephenhandley, have you tried using the codemod?
The codemod uses I just read your comment again; maybe I should clarified this first: is it just that the upgrade command with the |
This PR enables yarn 3 for Redwood projects. Right now, the goal is to do as little as possible (i.e., no breaking changes) to make this happen. So by yarn 3's standards, this is super hacky / all workarounds / very limited in scope (we don't plan on supporting just any install strategy yet).
Anyway, the goal is that users with existing Redwood projects can do something simple like this to upgrade:
Problem
Just to recap why we're doing this, yarn 3 has a lot more rules than yarn 1, one of them being that you can't run just any bin anymore. It has to be a bin of one of your top-level dependencies.
The way the RedwoodJS CLI works is that it's a bin of
@redwoodjs/cli
. It gets into projects via@redwoodjs/core
, so it's a dependency of a dependency. It's not top-level.That means after upgrading to yarn 3, you can't do this:
A visual way of seeing why is by running
yarn why
:@redwoodjs/cli
isn't a dependency of the root workspace, it's a dependency of@redwoodjs/core
, and that makes all the difference now.An easy way to solve this is to make
@redwoodjs/cli
a top-level dependency. Then you can runyarn rw
:But as @thedavidprice said, will it dev? No, because a lot of our CLI commands are really just
execa('yarn run ...')
statements, which brings us back to square one:Strategy
The strategy this PR uses is the one suggested by @larixer in the original issue: proxy bin invocations by listing them as
@redwoodjs/core
bins but really just requiring them from their true package location behind the scenes.An alternative to this is doing what we already do for the prisma command: just hardcode the path to the bin:
redwood/packages/cli/src/commands/prisma.js
Lines 82 to 91 in e7c4776
yarn 3 advises against doing this because it ties you to an install strategy (
node_modules
is just an implementation detail and may not exist at all depending on the install strategy). But we're ok with tying ourselves to an install strategy for now.Contributing
Half the reason this PR has been difficult is that the normal contributing flow doesn't apply. There's a temporary (i.e. I plan to remove it before merging) commit that adds a new contributing command
yarn project:yarn3
to enable trying out this PR locally:f0c0b96
(#4444).The script assumes you have a redwood project on yarn 3. I.e. you set your project to yarn 3 via
yarn set version stable
and copied the.yarnrc.yml
from the RedwoodJS framework to your project's andyarn install
.Note that since Redwood projects technically are using yarn 3 after running these steps (even though the CLI doesn't work), I tried
yarn patch
and theportal
protocol as contributing workflows, butyarn patch
doesn't work for bins since patches are resolved after bins, andportal
doesn't seem to 100% work 'cause we're still on thenode_modules
linker.Feedback
@merceyz, @larixer we welcome any feedback! We know that we'll have to refactor a lot of the CLI in the future to adhere to the new best practices (we may just distribute it as a separate binary and not run it via
yarn run
at all which may make things easier too), but for now we're doing what we can with what we have.CLI Commands Checklist
serverless
. I haven't confirmed it'll break but it looks like it will