Patching from a module

[ds300]

Patching from a module

[ds300]

Hmm. To my mind, patches are supposed to be temporary and/or application-specific. Of course it might be desirable to share a patch which solves a common problem. Is npm the right way to do that? I don't know. Maybe gists shared in Github issues would be lower-friction, and also healthier for the community because they promote merging fixes upstream. Or, rather, using gists wouldn't actively help people to forget about trying to merge fixes upstream.

Publishing a patch for a package makes sense if we think of it like creating a fork of that package but with an identical name. This is normally done behind closed doors, for one project at a time, and for very particular reasons, so I'm naturally worried that it could be too easy to cause nasty little conflicts if done with less certainty about the environment the patched code will run in.

Do you have a particular use case in mind?

[timarney]

Solid points - defiantly looking to keep the community healthy.

Here's my use case (trying to keep things easy to setup low friction):

I currently maintain react-app-rewired which essentially give you access to the webpack configs used by react-scripts.

This is currently done in a very hacky way:

const config = require(webpackConfig);
const override = require(paths.projectDir + '/config-overrides');
require.cache[require.resolve(webpackConfig)].exports = override(config, process.env.NODE_ENV);
require(paths.scriptVersionDir + '/scripts/start');

That works fine but is starting to fall out of sync with the main repo. I've had to copy over some files from the main repo to keep it running. There is an official way to fork react-scripts of course.

Figured I would try patching to expose the config as an experiment for the most part.

Generally the idea would be to create a patched copy that does the same thing as react-app-rewired. Thought it might be nice to be able to install the patch as a module than patch vs copying the patch manually etc...

Note: react-app-rewired isn't officially supported by CRA but it has been mentioned a few times as an option

[ds300]

Hmm yes, this kind of thing makes sense as a library and would probably be safe to do. The problem I can see is with DX.

Consider the installations steps:

1. Install react-app-rewired and patch-package

   yarn add react-app-rewired patch-package --save-dev

2. Set up patch-package in package.json

     "scripts": {
+      "prepare": "patch-package --apply react-app-rewired"
     }

3. Run patch-package once to get the ball rolling

   yarn prepare

4. Oh and by the way if you use yarn, go read the patch-package docs because running yarn remove might screw things up.

5. Create config-overrides.js

This would also create complexity around showing version mismatch warnings and patch application failure errors. Is it the end user's job to resolve those, or the patch's author? I would argue the author, so should patch-package tell the user to bug the patch author about a new version of react-scripts being released? I wouldn't want that as a user.

Compare with just forking react-scripts

1. Create your app using react-app-rewired scripts

   create-react-app my-app --scripts-version=react-app-rewired

2. Create config-overrides.js

And no mess. I know which one I'd rather use.

[timarney]

Ya very true. I'll ping you if a better lib use case comes up down the road.

[oklas]

Let me join in thanks and provide additional considerations

Version specification

Can the dependency version specification resolve mentioned above version-mismatch and patch-failure issue?

for suggested above example:

User installs module X which has patches for module Y runs

patch-package --apply module-x

Module X would contain the patches dir etc...

Where module X can have deps spec package.json like this:

"peerDependencies": {
  "react": ">=16.3.0 || ^16.3.0"
}

So user will see that module does not compatible with required deps and pr should be opened for module X.

Using steps

So mentioned above installation steps altogether:

1. Install react-app-rewired and patch-package

+ necessary

2. Set up patch-package in package.json

- must work using postinstall section (package.json of module X or as example for mentioned react-app-rewired)

3. Run patch-package once to get the ball rolling

- also must work using postinstall section

4. Oh and by the way if you use yarn, go read the patch-package docs because running yarn remove might screw things up.

- already solved by postinstall-postinstall

5. Create config-overrides.js

- library specific (required by design react-app-rewired)

So just install one additional library with patch is definitely easier than:

1. install patch-package
2. search through node_modules
3. edit line with problem * (multiply line count)
4. execute command to create patches
5. configure the package.json
6. do the commit
7. multiply above to count of projects

Another use case

Another use cases are the issues where authors does not accepts some feature asked by community due to worries or something else about community. For example remove this line currently suggested and worked around by many libs as suggested here (check emoji bar). There are same issues in some more or less popular libs.

Forks

And significant issue concern the forks. It is not only that that it is not easier than just install one deps. The most significant is that: some another library may use original library (not forked and not patched).

Together patched and original library may lead many problems:

• different behaviour for case patched/unpathced
• different versions
• different data structs
• different api
• unpredictable behaviour difficult to diagnose due to problems are not in code but due to code duplication

So forks in many cases are not applicable at all.