Here are approaches I use:
a) Make changes in the minified source to understand the problem, then go make changes in the original; or:
b) git clone dependency.git
cd dependency
yarn
yarn link
cd project
yarn link dependency
make changes in dependency
yarn run build
test my app
repeat until fixed
clean up, commit, and PR
I prefer B, but I'll do A first if the build step is annoying or slow.
I'm not expecting frictionless per se. But it just feels like there's more overhead than there needs to be.
Also, it's possible (in rare cases) the vendor folder is not .gitignore'd. Now what? Submodules is out.
Again, given the nature of most modern dev (i.e., dependencies) vit feels underprepared.
Re: "...but by switching away from the original you lose tooling support for telling you when you need to make that update..."
Yes. But doesn't this actually support the idea (mentioned above) not to treat your dependencies like black boxes? That is, no pain no gain? Yeah, perhaps some sort of simple notification your fork needs an update. Just the same, ALL code should, in theory, be treated as your own. You wouldn't blindly merge/commit a colleague's work, so why shouldn't your dependencies be semi thoroughly reviewed as well?
Are we too busy to do the right thing(s)?