Tanstack Start | The "Dependency Cutout" Workflow Pattern

The "Dependency Cutout" Workflow Pattern(blog.glyph.im)

18 points by ingve 2 days ago | 5 comments

I am using Git submodules for dependencies. My approach to a situation like this:

    1: Clone gh.com/someone/LibBar to gh.com/me/LibBar
    2: Fix the bug
    3: Send pull request to someone
    5: git submodule set-url lib/LibBar https://gh.com/me/LibBar.git
       git submodule sync lib/LibBar
       git submodule update --init --remote --recursive lib/LibBar
       cd lib/LibBar/; git checkout main; cd ../..
       git add .; git commit -m "Use my own version of lib/LibBar"

And keep using my fork until upstream accepted my pull request. Then I switch the url of the dependency back.

a_t48 2 days ago
For me it usually looks like:
```
    - Fork LibBar on Github, apply patch
     - In docker stage build-bar:
        - RUN git clone gh.com/my_org/bar
        - WORKDIR bar/build
        - RUN cmake .. -DCMAKE_BUILD_TYPE=Release (old habits die hard, need to remember to use -B)
        - RUN make -j
     - in main docker stage: --mount from=bar,src=bar/build,target=/tmp/bar make install
```
...and that's it. A little bit of wastage if I had to install over the top of some apt install but oh well. If I contributed back to upstream, or they fix independently, gravy - remove the extra build. This doesn't work as well for python or js, of course, and doesn't "solve" pulling in upstream regularly, but I usually don't need to. Benefits of not usually working on internet facing software, I suppose.
The python case is thankfully usually not terrible nowadays (clone, `uv build`, push to artifact registry), modulo needing to pass whatever flag to uv to let it take into account both my private registry and public pypi at the same time.
- aitchnyu 2 days ago |parent
  Does Python ecosystem have a patch-package equivalent?
  https://www.npmjs.com/package/patch-package
JackSlateur 2 days ago
tldr: create a fork, fix the fork, use the fork. When upstream is fixed, remove your fork.
It thought that this was option #2 but apparently no
- skeeter2020 2 days ago |parent
  I guess it's a technicality because the original option #2 is permanent, while the proposed solution is theoretically temporary (IME this approach will end up being permanent too based on how many companies operate). I actually think more companies should do this pre-emptively; it's very little extra work on the happy path (i.e. 1:1 with upstream) and you're ready to go when you need to deviate or fix and gives you better isolated supply management for your dependencies.