Hacker News new | past | comments | ask | show | jobs | submit login

I understand there are workarounds, but they are just that. I mean, for example, I'm working away but hit a bug in a dependency. Now i have to fork, submodule, etc.

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)?




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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: