7 Matching Annotations
- Dec 2020
You can afford to make a proper PR to upstream.
The change would be useful to other people as-is.
The change is too consequential to be developed in situ.
Patches can be reviewed as part of your normal review process, forks probably can't
Get told in big red letters when the dependency changed and you need to check that your fix is still valid.
Keep your patches colocated with the code that depends on them.
Sometimes forks need extra build steps, e.g. with react-native for Android. Forget that noise.
- patching (patching vs. forking)
- when to _
- taking the time to do it right/properly
- patching vs. forking
- code organization: co-location
- errors/warnings are helpful for development
- doing it right/properly
- forking (patching vs. forking)
- review process
- limited time: not right now (maybe later)
- pull request
- too hard/complicated/non-trivial