I am starting to try to modify the yarn rwfw script to run as part of my docker container build so that critical issues may be fixed in production ahead of the official redwood release.
Is there currently a way people are doing this?
I haven’t heard of anyone doing that.
You know you can do yarn rw upgrade -t canary, right? We build a canary version every time we merge a PR
1 Like
That’s what I do – upgrade to the canary release that includes the fix (aka merged PR’s) and then deploy.
You can see with canary release has the PR here: Actions · redwoodjs/redwood · GitHub
IMHO it is risky to rely on the redwood team’s availability.
I think actually the most likely production setup that would scale beyond the redwood’s team ability to quickly merge a fix and release canary within every possible user SLA, is a fork that is basically stable redwood (to insulate from bleeding edge bugs) plus team/company specific updates.
Have not gone live yet but this is on my list of required todos
@thedavid, @Tobbe and others - do other people use yarn’s patch package to update their own deploys?
In the context of production, this would be brittle. But I like your thinking.
Definitely look into Yarn patch. Used it and really like it:
IMHO it is risky to rely on the redwood team’s availability.
A question that’s of much more interest to me — what are you building?!? Maybe we can help close the gap between your project and the Redwood Core Team:
The application we’re trying to build has a low level of load, but a high cost to internal errors - users are doing something they really don’t want to do at all, that is inherently tedious, so they’re already frustrated and will loudly complain if anything doesn’t work
I know of at least one possibly two companies doing that. Don’t want to call anyone out here though.
One limitation to patching is you can’t edit a package’s package.json which I’ve wanted to do before.
We (the RW core team) tried building RW packages for every PR that came in. @twodotsmax would that help you? If we could get that working (again) you’d only have to submit a PR and a few minutes later you’d have a package you could use. I know someone used one such pr package in production for quite some time
I don’t think just keeping production in sync with the latest Redwood PRs would help.
- People merge bugs too
- In this example PR (Fix Maximum Call Stack Size Exceeded when using requireAuth with Function on non-lambda environment by twodotsmax · Pull Request #5094 · redwoodjs/redwood · GitHub) I fixed a bug that totally shut down all Functions that require a user auth token for non lambda deployments. This would be a p0, hair on fire issue because users would be unable to perform critical actions 100% of the time (so effectively downtime). It took 4 days for the PR to be merged. Assuming there is an issue like this discovered once a month that’s like 13% downtime / not even one 9. It took me 45 minutes to fix the problem so it would have probably been 1-2 hours end to end if I had the ability to make any change to redwood and deploy immediately which is 99.7% uptime. So I will probably be going with yarn patch as thedavid suggested.
For me, @twodotsmax - I understand, however from our perspective, we cannot merge PRs until:
a) We fully understand the problem, or reproduce it. One way to get PRs in quicker, is to spend a little bit more time on the description, reproduction and why/how the changes were made
b) If possible add test cases (unless the PR actually does this for us) - this is a big plus
c) Are able to consider the implications on other parts of the framework
If you would like to patch things within your node_modules - whether that’s Redwood, React Native, React, Svelte - whatever - your main option is to use https://yarnpkg.com/cli/patch or patch-package - npm
This is the nature of building software with third party packages - but remember what you get in return is probably built-in solutions for 100 bugs you would find had you rewritten all yourself!
1 Like
@twodotsmax I would also recommend patch-package for fixes that has yet to be issued, merged or released.
Yeah, I think your review was relatively quick, just illustrating the need for quick patching on our end. 100% agreed that the community contributions are worth the risk
Okay ultimately what I am doing is using yarn project:deps and yarn project:copy with redwood fully inlined into my app repo that the GCP build system uses for the docker image. Is there any way that could be incorrect?
project:copy has a bug as of Yarn 3 change. Will bust on repeat use.
Did Yarn patch not work?
yarn patch requires you to have a script that makes the tmp dir, moves the edits into the dir, and commit, for each package
but if I have to do that I will - don’t know much about yarn so will have to get up to speed on that migration, yarn patch fails locally because I’m on 1.x
I guess I’m not following what you’re trying to do here. I work with yarn patch locally, run through all CI, then deploy.
Also related:
Following up on this. I upgraded to yarn 3 so that we can avoid using the soon to be broken script. However, my patches don’t work and I think it might be due to the fact that the target package, @redwoodjs/api-server, is not a direct dependency of my project. Is it possible to patch it so that redwood will use the patched version? The root project only depends on @redwoodjs/core.
EDIT: Nevermind, I didn’t run yarn after adding the patch. All good now
1 Like