What is/should be the approach for "patching" dependencies?

Brainstorming
1

Maybe makes more sense in the Explain category if there’s already a decided approach, and potentially similar to this topic.

What should be the approach for “patching” dependencies? I’m thinking in the style of pnpm patch or something like that - editing the code for an existing dependency (or transient dependency).

2

Easy answer is vendor your dependency and modify it.

At work we have a more complex setup with Bazel that apply patch files to a given dependency. Including LLVM and Zig itself.

Of course that’s not the recommended beginner approach.

3 Likes
3

With v0.16.0, packages are fetched and put in the zig-pkg folder. It is possible (and encouraged) to muck around with those files. You can even commit them to source control.

The most straightforward way would be to commit any changed files for the zig-pkg folder so that om a checkout you get the updated version.

Another option would be to have something in your build script that patches files. That would be more one-off style setups, not the nice patch subcommand like (p)npm has.

2 Likes
4

Open source workflow:

  1. Fetch the dependency source code to your computer
  2. Check out the version that you are using
  3. Use the --fork flag in your project to swap your dependency for that
  4. Try a newer version of the dependency to see if it fixes your problem
  5. Try patching the dependency to fix your problem
  6. Send the patch upstream
  7. Push your fork somewhere
  8. Update your project to use your fork while waiting for upstream
  9. Work with upstream to get your patch landed
  10. After upstream makes a release that includes your patch, switch back your dependency to upstream
  11. Delete your fork
15 Likes
Discussion of zig build and lower level direct invocations
5

15 posts were split to a new topic: Discussion of zig build and lower level direct invocations