5

Please consider the following scenario:

  1. There is an npm package named some-package.
  2. There are a couple dozen known dependent npm packages that all depend on some-package.
  3. I forked some-package and made a breaking change to its API.
  4. I forked all dependent packages that I care about and updated them to use the modified API and also pointed them to use my forked some-package instead of the original some-package.

From here onward, I have no desire to make further changes to either some-package nor the dependent packages. I wish for all non-conflicting changes that are made in the original repositories to be immediately merged in to my corresponding repositories. I wish to release my versions of these packages any time the original packages are released.

Are there any tools that can help with this? This is a lot of maintenance that I don't want to have to deal with manually. I understand what actions I can take to keep these up to date myself, but I don't really want to deal with it constantly. And getting my changes merged in to the original repository seems unlikely, so this will be a persistent issue for me.

Kelsie
  • 167
  • 1
  • 1
    What is a 'non-conflicting change'? Would you consider that to be one that doesn't require a merge conflict resolution but breaks some functionality? To error is human but to really mess things up takes a computer. I believe part of the possible answer here is "that *is* the responsibility of the maintainer." –  Dec 10 '15 at 16:03
  • 1
    I believe that maintaining issues like this would be my responsibility, obviously. I'm fine with that- that's what unit tests are for anyway. But it would be cool if there are any automated processes that can get me in to that spot to begin with. Because most of the time, it's going to just work and I won't have to fuss with it. – Kelsie Dec 10 '15 at 16:05

0 Answers0