6 ms·

On github and the node/JS ecosystem, the way this will play out: 1. Spend hours digging through layers and layers of crufty JS. 2. Find the issue (and t

On github and the node/JS ecosystem, the way this will play out: 1. Spend hours digging through layers and layers of crufty JS. 2. Find the issue (and the package responsible for the issue). 3. Find out there is a Github Issue for the issue. 4. Find out there is a pull request for the issue. 5. Find out the pull request is sitting in position #35 of #128 pull requests going back to 2015. 6. Go binge drinking.

rudasn 9y ago
7. (next morning) Fork the project, apply your PR and any others you like, and use your fork in your codebase. 8. (optional) Thank the creators and maintainers for the time and effort they put into it.
- yoz-y 9y ago
  This is not always an optimal solution. Because by doing this you have essentially became a maintainer of a dependency you initially wanted to 'just' use.
  - RobertRoberts 9y ago
    This is sadly why I keep my dependencies to a minimum. After coding for almost 20 years now, full time, I have never regretted not using a dependency. But I have regretted using one multiple times. (the regret is like a walk of shame during the "separation and cleanup" phase at the end, which makes me question the "got work done faster" phase at the beginning....)
    - bryanrasmussen 9y ago
      In 20 years you've never started work on something and after a bit said damn it I think I'll use that library that other guy developed? If you've ever switched out dependency X for dependency Y I suppose you regretted not using Y to begin with. If you've ever stopped working on your own solution to a problem and instead used a solution provided in a library didn't you regret not just using the library from the beginning?
      - sgtmas2006 9y ago
        Sometimes yes, sometimes no. I've abandoned writing something to use a dependency in place that got the job done, but could have a number of improvements.
      - RobertRoberts 9y ago
        >In 20 years you've never started work on something and after a bit said damn it I think I'll use that library that other guy developed? nope, I am just saying what I said, I never regretted not using one, and have regretted investing in a few that later caused more headaches than they were worth. When we switched from inhouse code to a dependency, we never regretted doing it on our own to start with because there was so much insight gained from this and many other side benefits (like direct control, intuitive understanding of how our code worked, etc...). But when you have a dependency you add that you later have to work around, you simply can't fix in the same way can your own code, and you just hate the mess in a totally different way. When it's your own code, you can fix anything. And replace it a piece at a time if need be. With a dependency, there's usually catches, hacks or work arounds, or conflicts built up over years that finally have come to a head. And it sucks to fix and in many cases if I had waited even a little while, or did more research at the time, I would have picked a different dependency or none at all. There are a lot of dependencies we use, I don't think you can run a business properly these days without them. They just are not a part of our core systems anymore. We use them for tertiary systems and addons, things that a replaceable. Then our core systems can't be hijacked by stuff like the latest NPM debacle.
        Ace17 9y ago
        Yeah, this also matches my (+10 year) experience as a professionnal dev ... with one exception, though: the "maintainance-can-of-worm" packages. These are packages which, by design, can never be considered as finished, and periodically need to be updated to stay relevant in your application. There are three reasons for this: 1) Those packages implement an ever-growing pile of tricks/heuristics to convincingly solve problems from the domain. They include: physics engines, SMT solvers, compilers/jitters/optimizers, computational geometry packages, video encoders ... 2) Those packages implement an unification layer over an ever-growing/evolving set of underlying APIs/protocols/formats. They include: SDL, ncurses, curl, ImageMagick ... (these are not to be confused with "bug-factories" packages, which might not solve a complex problem, but still require constant updating to fix the current bugs, and benefit from the new ones).
    - choonway 9y ago
      It's ASIC vs FPGAs...
    - gt_ 9y ago
      I have only been coding for 1.5 years and this kind of comment is validating what I worry is a very bad habit. I hate using dependencies unless they have reached a certain level of legend in the community.
      - FLUX-YOU 9y ago
        This is a normal feeling. But one weakness of this approach for javascript is that it's easier to become popular because you have a much larger base of developers.
        gt_ 9y ago
        That makes sense. I use Python the for most part. I feel like I have seen this happen with old libraries where they used to be very popular and maintained then became abandoned a few years ago.
        funkymike 9y ago
        That can be okay. Depending on the nature of the library it might legitimately be "done." Personally, I would rather see this than a bug fix being committed every week. That makes me question how many more bugs there are and how much I'm going to have to babysit updating the dependency.
        gt_ 9y ago
        That's a great point. Hmmm... I wasn't considering that. Oops. I'm glad I mentioned it! Thanks!
      - RobertRoberts 9y ago
        >...unless they have reached a certain level of legend That is a similar tactic I use now for anything core. I know I commented that we don't have any dependencies in our core systems, but as an afterthought, this isn't entirely accurate. We do, but as you said they are "legendary", and don't change a whole lot anymore. I think you are on the right track. :) Edit: Keep business practicality in mind, if using a 3rd party library means you feed your family or are productive for the business, you need to weigh these considerations carefully. It's likely you need to use a dependency to get your work done, and then later when you are more profitable, you can clean it out if need be. Maybe that is how I should have worded my first comment in retrospect.
  - eloisant 9y ago
    That's a last resort, but it's important to remember that the option is on the table. Then consider ditching this dependency (either by switching to a different one or with your own code) if the maintainers are not active enough.
  - PeterisP 9y ago
    Well, that's kind of the point - (almost) everybody wants to just use the dependencies, but someone must maintain them for the community to work.
seattle_spring 9y ago
7. Find out that the sole maintainer of the repo is a "well-respected influencer" in the JS community, and actually has a blog post stating that GitHub should remove the "issues" feature and instead only allow contributions via Pull Requests.
lloyd-christmas 9y ago
In my last 4 years of working in node, I've had this issue once. I think you people need to pick better dependencies.
- deckard1 9y ago
  webpack. My dependency was webpack. It was a dependency of webpack that was broken (you can pick your bride, but you can't pick your bride's family). And the package owner, in a Github Issue said "not my problem, this package should never be used with webpack and should only be used with Browserify." Looking at the date, that Issue discussion occurred in 2015. Which makes sense. But a WONTFIX on a package that obviously is broken (I looked at the code), and is still an issue in 2018 is clearly a problem. The node world is a circular firing squad where no one wants to take responsibility for fixing their shit because each person thinks they are doing the right thing. When, thanks to the mess of npm, no one really knows who the "user" of their package is and you can't just dictate that so-and-so shouldn't be using your package that way. Because someone will use your package that way. WONTFIX, issues just suddenly "closed" without reason (why, dammit??), or pull request queues 100+ long and obviously unmaintained are way too common for me. I've lost track of the number of times this has occurred.
jacinabox 9y ago
And then there's the problem that you can't hardly convince the maintainer that something is an issue unless they have the issue on their OS and configuration.

rudasn 9y ago

7. (next morning) Fork the project, apply your PR and any others you like, and use your fork in your codebase. 8. (optional) Thank the creators and maintainers for the time and effort they put into it.

yoz-y 9y ago
This is not always an optimal solution. Because by doing this you have essentially became a maintainer of a dependency you initially wanted to 'just' use.
- RobertRoberts 9y ago
  This is sadly why I keep my dependencies to a minimum. After coding for almost 20 years now, full time, I have never regretted not using a dependency. But I have regretted using one multiple times. (the regret is like a walk of shame during the "separation and cleanup" phase at the end, which makes me question the "got work done faster" phase at the beginning....)
  - bryanrasmussen 9y ago
    In 20 years you've never started work on something and after a bit said damn it I think I'll use that library that other guy developed? If you've ever switched out dependency X for dependency Y I suppose you regretted not using Y to begin with. If you've ever stopped working on your own solution to a problem and instead used a solution provided in a library didn't you regret not just using the library from the beginning?
    - sgtmas2006 9y ago
      Sometimes yes, sometimes no. I've abandoned writing something to use a dependency in place that got the job done, but could have a number of improvements.
    - RobertRoberts 9y ago
      >In 20 years you've never started work on something and after a bit said damn it I think I'll use that library that other guy developed? nope, I am just saying what I said, I never regretted not using one, and have regretted investing in a few that later caused more headaches than they were worth. When we switched from inhouse code to a dependency, we never regretted doing it on our own to start with because there was so much insight gained from this and many other side benefits (like direct control, intuitive understanding of how our code worked, etc...). But when you have a dependency you add that you later have to work around, you simply can't fix in the same way can your own code, and you just hate the mess in a totally different way. When it's your own code, you can fix anything. And replace it a piece at a time if need be. With a dependency, there's usually catches, hacks or work arounds, or conflicts built up over years that finally have come to a head. And it sucks to fix and in many cases if I had waited even a little while, or did more research at the time, I would have picked a different dependency or none at all. There are a lot of dependencies we use, I don't think you can run a business properly these days without them. They just are not a part of our core systems anymore. We use them for tertiary systems and addons, things that a replaceable. Then our core systems can't be hijacked by stuff like the latest NPM debacle.
      - Ace17 9y ago
        Yeah, this also matches my (+10 year) experience as a professionnal dev ... with one exception, though: the "maintainance-can-of-worm" packages. These are packages which, by design, can never be considered as finished, and periodically need to be updated to stay relevant in your application. There are three reasons for this: 1) Those packages implement an ever-growing pile of tricks/heuristics to convincingly solve problems from the domain. They include: physics engines, SMT solvers, compilers/jitters/optimizers, computational geometry packages, video encoders ... 2) Those packages implement an unification layer over an ever-growing/evolving set of underlying APIs/protocols/formats. They include: SDL, ncurses, curl, ImageMagick ... (these are not to be confused with "bug-factories" packages, which might not solve a complex problem, but still require constant updating to fix the current bugs, and benefit from the new ones).
  - choonway 9y ago
    It's ASIC vs FPGAs...
  - gt_ 9y ago
    I have only been coding for 1.5 years and this kind of comment is validating what I worry is a very bad habit. I hate using dependencies unless they have reached a certain level of legend in the community.
    - FLUX-YOU 9y ago
      This is a normal feeling. But one weakness of this approach for javascript is that it's easier to become popular because you have a much larger base of developers.
      - gt_ 9y ago
        That makes sense. I use Python the for most part. I feel like I have seen this happen with old libraries where they used to be very popular and maintained then became abandoned a few years ago.
        funkymike 9y ago
        That can be okay. Depending on the nature of the library it might legitimately be "done." Personally, I would rather see this than a bug fix being committed every week. That makes me question how many more bugs there are and how much I'm going to have to babysit updating the dependency.
        gt_ 9y ago
        That's a great point. Hmmm... I wasn't considering that. Oops. I'm glad I mentioned it! Thanks!
    - RobertRoberts 9y ago
      >...unless they have reached a certain level of legend That is a similar tactic I use now for anything core. I know I commented that we don't have any dependencies in our core systems, but as an afterthought, this isn't entirely accurate. We do, but as you said they are "legendary", and don't change a whole lot anymore. I think you are on the right track. :) Edit: Keep business practicality in mind, if using a 3rd party library means you feed your family or are productive for the business, you need to weigh these considerations carefully. It's likely you need to use a dependency to get your work done, and then later when you are more profitable, you can clean it out if need be. Maybe that is how I should have worded my first comment in retrospect.
- eloisant 9y ago
  That's a last resort, but it's important to remember that the option is on the table. Then consider ditching this dependency (either by switching to a different one or with your own code) if the maintainers are not active enough.
- PeterisP 9y ago
  Well, that's kind of the point - (almost) everybody wants to just use the dependencies, but someone must maintain them for the community to work.

seattle_spring 9y ago

7. Find out that the sole maintainer of the repo is a "well-respected influencer" in the JS community, and actually has a blog post stating that GitHub should remove the "issues" feature and instead only allow contributions via Pull Requests.

lloyd-christmas 9y ago

In my last 4 years of working in node, I've had this issue once. I think you people need to pick better dependencies.

deckard1 9y ago
webpack. My dependency was webpack. It was a dependency of webpack that was broken (you can pick your bride, but you can't pick your bride's family). And the package owner, in a Github Issue said "not my problem, this package should never be used with webpack and should only be used with Browserify." Looking at the date, that Issue discussion occurred in 2015. Which makes sense. But a WONTFIX on a package that obviously is broken (I looked at the code), and is still an issue in 2018 is clearly a problem. The node world is a circular firing squad where no one wants to take responsibility for fixing their shit because each person thinks they are doing the right thing. When, thanks to the mess of npm, no one really knows who the "user" of their package is and you can't just dictate that so-and-so shouldn't be using your package that way. Because someone will use your package that way. WONTFIX, issues just suddenly "closed" without reason (why, dammit??), or pull request queues 100+ long and obviously unmaintained are way too common for me. I've lost track of the number of times this has occurred.

jacinabox 9y ago

And then there's the problem that you can't hardly convince the maintainer that something is an issue unless they have the issue on their OS and configuration.