16 ms·

Lodash just declared issue bankruptcy and closed every issue and open PR

240 points by omnibrain 3y ago

davidmurdoch 3y ago
Relevant recent tweet from lodash's creator: https://x.com/jdalton/status/1701015897702572335?t=YLClO1zWazNXh3YkMilJYA&s=09 https://x.com/jdalton/status/1701015897702572335?t=YLClO1zWa...
bluefirebrand 3y ago
Lodash is a great library. It's something I wind up using a little bit of on almost every project I work on. However, as JavaScript has become better and better, I use Lodash less and less. Every time I catch myself using it, I make sure to go see if there's a built-in for what I'm trying to do. I also find myself commenting on PRs with links to "you don't need Lodash for this" quite often. I still hope this isn't a sign they are stepping away from the project.
- darepublic 3y ago
  It's definitely convenient but I think invariably I would prefer to just roll my own versions of its utils if it came down to it
  - BoiledCabbage 3y ago
    Why?
    - kakadoodle 3y ago
      Maybe start explaining why not, and then ask why someone would? I think it would create a more interesting conversation.
    - 0000000000100 3y ago
      Less dependencies makes maintaining the project easier.
      - erik_seaberg 3y ago
        Popular libraries have been battle tested in prod, and my teammates probably have prior experience with them.
        darepublic 3y ago
        There are more than a few popular js libs that are pretty trash IMO. Though I would not count lodash among them. Battle tested can often just mean teams use them for better or worse, and I can often see in the code how bad frameworks cause juniors to contort their solutions in all the wrong ways to make them adhere to a framework instead of untie the knot and do it the right way. Sometimes it is the framework being used incorrectly. The devs should invest time to learn the API better. But often it's better to just learn how to do the solution sans framework rather than add to the stack of bespoke APIs to learn. And junior devs can become dependent on frameworks for every little thing to the point where they will always reach for one even if the choices are poor
      - SkyPuncher 3y ago
        How? That’s more internal code with bugs.
        sebastianz 3y ago
        Some internal code with bugs is way better than lots of external code with other people's bugs.
        SkyPuncher 3y ago
        Pretty much disagree on every front. Particularly for a major library. There's a very good chance those "other people" have thought about the problem they're trying to solve way more than you have.
        yakshaving_jgt 3y ago
        You don’t think this learned helplessness is depressing? Whether or not a team decides to own some portion of code is a complex topic. Sometimes it makes sense to leverage something external, and sometimes it makes sense to write it yourself. In my business, we had a [ostensibly senior] guy insist we use an external technology because it would be too hard for us to own that piece ourselves, despite it being a core part of the product. Technical due diligence on the external technology showed that it didn’t actually work as advertised. Six figure price tag and apparently millions invested for a thing that doesn’t work (and “doesn’t work” in this case meant “corrupted financial data”). Whether or not a team owns some technology is highly context dependent, and your comment comes across as reductive.
    - darepublic 3y ago
      Because the surface area of lodash is so large and I need just a small fraction of it. And when I do need it it's easy to make a simple transparent version of the needed until rather than invoke a mystical black box. I admit this is opinionated and I have managed to work with lodash and keep my mouth shut about it
      - BoiledCabbage 3y ago
        Thanks for sharing - I disagree with the approach, but understand it. Or rather, I feel that can work for individual coding, or possibly very small teams - but in the end I feel it usually works out to be unintentionally anti-team behavior. It trades off "I need to learn and understand this black box of behavior for instead I have this code that I know and can easily reason about". While for the entire rest of your team it went from "there is this common pattern that most of all 20 (or however many) of us know - and instead makes it 19 of us now need to learn this non-standard behavior/implementation, but at least one person knows well." Essentially everyone else has to learn more code, so that one person doesn't. Agreed it's usually not the most complex of code, but it's usually buggier and shifts to cost / burden to everyone else. The opposite of economies of scale and leveraging prior fixed costs of learning. But again, I don't know your situation and will readily admit my opinion above doesn't in anyway make it factually a better approach. Just my opinion on it same as yours.
        rcme 3y ago
        It works perfectly fine. You just copy and paste the code you need. If someone else needs it, they search the code base first, which is normal in large code bases. There are tons of different libraries that provide deep equality checks for instance. When I work in a code base, I need to search for existing solutions in the code base before adding someone new. It doesn’t matter if the functionality is provided by a first or third part library.
      - xeromal 3y ago
        I'm not sure if you're aware but lodash has individual packages for each of their functions.
    - mostlylurks 3y ago
      Not super relevant for lodash in particular, but another reason for why someone might want to do this is dependency hell. At least with code you write yourself, you know that the author(s) won't keep changing the API (very common in the javascript ecosystem, unfortunately), forcing you to either waste time constantly changing your own code to match the newer APIs, or stick to a single version for a long time, which may become incompatible with newer versions of other dependencies, your build system, your language, your environment, etc, which will become an issue if you have something else that you want to update but that old version of the dependency doesn't support it. So in some cases it might be easier and more maintainable to just write your own version of whatever small feature of the dependency you might otherwise have used, but knowing when this will be the case is a skill of its own.
- jauntywundrkind 3y ago
  Very much agreed. The amount of mileage we get from using Spread (literally the ...) alone has been amazing. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Iteration helpers is shipping soon, that'll be a huge help (async iteration helpers will be delayed for a while). https://github.com/tc39/proposal-iterator-helpers https://github.com/tc39/proposal-iterator-helpers . In the olden days, I feel like the codebases I worked on needed to use .apply() multiple times a week, to figure out some creative way of invoking functions. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/apply https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... That's all gone now; I'd take even odds that 50% of my team knows .call and .apply. Chrome 117 is shipping Object.groupBy() and that's gonna be a huge help in eliminating a lot of the last places we end up using lodash. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/groupBy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- throw1234651234 3y ago
  I haven't used lodash or underscore.js since 8 years ago. I just don't see what it has that can't be accomplished easily with map / filter / find, etc.
  - JuanPosadas 3y ago
    I wish some of you-might-not-need-lodash websites would include the approximate file size savings with each featured function. Some of them can be 5kb for a single function.
SeanAnderson 3y ago
I am so conflicted on this! On the one hand, I fucking love it. Who hasn't experienced a backlog grooming session where you know it's impossible to reach the end of the backlog and you just sort of go along with the process of scraping from the top. There's definitely something miserable about that feeling. On the other hand, it's not like the issues are gone, they're just tagged differently, and if everything is just tags and organization then why not go with the flow rather than exerting control in an attempt to achieve this pseudo-perfect empty issue list. There's gotta be benefit in keeping those notes around and visible, right? Sort of feels like deciding to throw something out of your house while deep in a cleaning spree even though your subconscious is (reasonably) nagging at you to hold onto it because you might need it in the future. On the whole I think I'm for it, though, if anything just for the cathartic release and presumed re-invigoration towards new issues.
- etler 3y ago
  For a bit more context, the creator is doing a full rewrite. I think it would probably have been cleaner to release the rewrite first, then close all the old issues as deprecated. You could isolate the rewrite branch issues with a version tag. Closing then while the new version isn't done may lead to contributers opening new issues on the old version without realizing that it is no longer supported. But he's not just ignoring the issues and leaving problems in the code base, the entire project is getting a refresh. https://twitter.com/jdalton/status/1571863497969119238 https://twitter.com/jdalton/status/1571863497969119238
  - brailsafe 3y ago
    I like it, it's the "put everything in a giant mailbag, label it, and dump it in a storage locker" approach. If the issues are still relevant, they can be resurfaced.
    - ImPostingOnHN 3y ago
      "...and when resurfaced, they will be stuffed into the 4th mailbag for further 'resurfacing'"
vosper 3y ago
What is issue bankruptcy? Is it declaring that you don’t have the resources look at the issues? It seems much better to tag them like Lodash has done rather than let open issues pile up like many other low- or no-resource projects do.
- klardotsh 3y ago
  In IRL bankruptcy you declare you can't possibly pay back your creditors and lose "most" non-trivial assets as they're liquidated off to attempt to make a few pennies for those creditors as you rebuild your life from 0. Lodash just decided to rebuild from 0 - literally, actually, since it's a rewrite, but especially in the bug tracker sense of the word.
- jowea 3y ago
  Have you heard of email bankruptcy? When you empty your inbox unread and start over again.
pxue 3y ago
select all open issues, Tag: won't fix, close. Restart cycle.
romellem 3y ago
John-David Dalton, the lodash author, wrote [this last year][1]: > For the lodash rewrite I’m declaring tech debt bankruptcy. Starting from scratch with TypeScript and Rollup. No FP wrappers. That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly. Don’t know if he’s sticking to this 100% but seems pretty close. [1]: https://twitter.com/jdalton/status/1571863497969119238 https://twitter.com/jdalton/status/1571863497969119238
- gorgoiler 3y ago
  What were FP wrappers and what was the fad?
  - stolenmerch 3y ago
    "Auto-curried function style (reversed arg) wrappers" https://twitter.com/jdalton/status/1571870137690591236 https://twitter.com/jdalton/status/1571870137690591236
    - legulere 3y ago
      And what is that?
      - janehdoch 3y ago
        [flagged]
      - gorgoiler 3y ago
        Specifically I don’t know, though I do know what currying is. This auto-currying thing sounds like a reaction against some parts of JavaScript where you can get burned by default arguments. A curried function is like a partial application for each argument. If mul:=(a,b)=>a*b then currying would be being able to say double:=mul(2). Currying everything and requiring all function calls to have one parameter per call — six:=mul(2)(3) — might have some benefit in avoiding bugs. Generally speaking though my hunch is that the lodash author grew tired of the project’s focus on meta programming: noodling around with JavaScript using programming paradigms that hinder rather than help its users. Dropping the noodling and focusing on features is a “back to basics” moment, if you will.
beebeepka 3y ago
I never liked lodash, even when when it was new. These days I just laugh when people tell how great it is. Useful? Sure. But if you care about performance and simplicity, just spend a day or two writing your own versions of the things that you need. Or, if rolling home made is not to your liking, go with ramda. Edit: downvote vall you want but at least have a look at lodash internals just in case. What an overcomplicated mess. It's old, really old.
- K0balt 3y ago
  He’s rewriting from scratch in typescript.
- SparkyMcUnicorn 3y ago
  Looking at the internals is often why I choose to use it. It catches edge cases I might not think of, and the performance tradeoffs have been negligible to none. I don't use it for everything, and definitely try to use native and/or narrower scope methods when it makes sense, but it's saved me a lot of time and headache throughout the years.
- paulgb 3y ago
  Are there functions where the performance is significantly worse than what you could write on your own? Not a rhetorical question. I don’t use lodash but as a primarily non-JS dev I’ve referred to the source some times when I’m writing JS as a reference for the idiomatic way to do simple things. I’ve found some weird things, like isEmpty is technically O(n), but this turns out to be a limitation of JavaScript rather than a lodash issue.
  - eyphka 3y ago
    There are a couple of weird things in my experience, like the old implementation of zip, but by and large it was mostly either restrictions of js itself or browser implementations of js. Lodash has and still is a good standard / reference for these simple operations imo.
  - mediumdeviation 3y ago
CodeWriter23 3y ago
Everyone gets a feature!
pscanf 3y ago
Well done! Looking at the first few PRs in the list, you can see things like: - Adding a word in a comment. - Adding config files to self-promote dev services. - Switching from using var to let. - Changing well-established behaviours of core functions. - Removing semicolons. - ... I'm sure most of those were opened with good intentions of improving the library, but at some point for the maintainer they just become spam (or worse, a growing burden that makes you feel guiltier and guiltier for not giving it attention). Celebrities hire bodyguards and fly first class (or private) to avoid the constant stream of attention and keep sane. I wonder what measures could be taken by celebrity OSS projects.
- EdwardDiego 3y ago
  > Switching from using var to let. One particular GH user submitted multiple PRs doing only that. Across multiple JS projects... ...feels like GH profile padding.
  - fmajid 3y ago
    Not so much padding the profile as making the github contribution graph more solidly green.
- Null-Set 3y ago
  There was a trend for a while for people to open trivial PRs against popular projects, I believe in an attempt to pad their resumes.
  - kynetic 3y ago
    This is still a trend unfortunately.
  - gochi 3y ago
    They can keep padding their resume if it means little fixes actually happen. Even typos and little translations, they affect the general reputability of the software. Sounds like a fair trade, especially as most hiring companies can just look at PRs and see what was actually changed very easily.
erik_seaberg 3y ago
As jwz put it > This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch—and the new maintainer can’t be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.
- hackermatic 3y ago
  It's like that with security findings, too.
- neilv 3y ago
  And a variation on that: the issue was reported against one major release, but a new major release (just incremental changes, not rewrite) is coming out, so close all issues against the old release, because the problem might no longer exist.
  - RaisingSpear 3y ago
    Or simply: > report issue > issue is automatically closed 6 months later due to lack of activity ...with absolutely no change to or comment on the issue.
- jauntywundrkind 3y ago
  Make a PR with some tests that should pass, but are instead marked skipped. That way when the rebuild comes around, there's an easy path for the rebuild to see how it's doing, see if things are at all improved. If you care about it, you should put a test on it.
  - erik_seaberg 3y ago
    I’m probably not enough of an expert on their code to write that unit test. And I don’t have much faith in a team who blindly closes bugs to unskip tests and upgrade them to the new API.
  - 3y ago
smitop 3y ago
The bigger news is that Lodash is migrating from Node.js to Bun: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d7b813bed96b35b5abf15#diff-9ef15c0955375fd602c4e30fb95794a5d5b33909fe57f0e79127afa10ce578f3 https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...
- firtoz 3y ago
  Woah. I was starting to get excited about migrating my packages to Bun, but hesitating because I was afraid of compatibility or whether Bun is really here to stay or not - I have been slightly burnt by "Modern Yarn"; but honestly, seeing lodash make the leap makes me want to consider it more seriously now.
  - steve_adams_86 3y ago
    I’m a yarn burn victim as well, and it has made me a lot more apprehensive about fundamental decisions like these. They seem so promising and your research seems to check all/most of the boxes… Then you get Yarn 2/3
    - dheerajvs 3y ago
      What's wrong with yarn 2+ (berry)?
      - steve_adams_86 3y ago
        My issue is the substantial shift in the API, major bugs and poor documentation in the initial workspaces implementation, then more subjectively, I didn’t like the PnP solution though it seems to work more reliably now. I worked on a very large monorepo that was using yarn and the headaches that occurred from migrating to workspaces and newer versions of Yarn were absolutely brutal. In many ways things were better and other package managers technically couldn’t offer the same features, but there’s a reason packages like Lerna/Nx/Turborepo were used to accomplish similar things despite it being possible with yarn. It was extremely cumbersome, didn’t work intuitively with TypeScript, felt like a house of cards at times, etc. I understand it’s better now, but getting hit by that transition was a burn if I ever saw one.
Supply5411 3y ago
Issue bankruptcy is real. Speaking from personal experience, at some point maintaining OSS is incompatible with living in the real world. The work is free and often thankless (but not always). The problems are complex and compete with real world responsibilities, like work, family, rest. People get pissy and regularly want to argue with you or read the docs for them. It also carries enormous responsibility if your OSS is popular. I am anticipating a huge collapse in the OSS ecosystem as the people who drive them say "fuck it" and walk away for more important things.
- eternityforest 3y ago
  That I can understand. These days I'm almost starting to think of nontrivial personal projects as more an addiction or self harm than real projects. The OSS ecosystem is insanely inefficient though. There's lodash, underscore, and plenty of others. They don't all need to exist. There's also lots of libraries that only do one thing, which are mostly a subset of something like this. Most of this stuff will be used with minifiers and tree shaking, and unused features will be removed, we don't need lightweight libraries when the heavy ones are easily optimized and mostly made of separate parts, so the dev effort mostly scales linearly. I think OSS has plenty of manpower, even if everyone decided to only spend a quarter of the time they currently spend, if it weren't for the fact programmers like elegance and simplicity more than anything, and constantly want to rewrite to make things just a little bit better.
xwdv 3y ago
I wonder if for some very popular open source libraries, charging a small fee to report an issue might be some kind of viable business model, or at least a way to prevent too many issues. You might say this will result in people not reporting legitimate issues, but as we can see in this case it’s not the end of the world.
- JuanPosadas 3y ago
  I think it would be cool if any user could add bounties to any issues and the maintainers could sort by highest bounty and then complete those first.
monksy 3y ago
I wonder if this would be a thing if everyone who created an issue had to reproduce it via a test.
zadokshi 3y ago
Let the one who throws the first stone at the “closed / won’t fix” manager, themselves be the person that has to fix it.
hedora 3y ago
I hadn’t heard of lodash. From Wikipedia: > Lodash is a JavaScript library that helps programmers write more concise and maintainable JavaScript. I love the sweet, sweet irony! (“Blind leading the blind”, and all that.)
- earthboundkid 3y ago
  There was a time when it (or underscore.js, its predecessor) was a useful collection of Array methods, but since then almost everything of value in underscore has been added to the Array prototype itself, so I don’t really see a point in using it anymore. The devs know this too, so now they’re just bored and rewriting for no particular reason.
panic 3y ago
Issue trackers have two overlaid uses. First, they’re a way for maintainers to keep track of work they have to do, and second, they’re a way for the larger community (including users) to keep track of defects in the software. Declaring “issue bankruptcy” makes sense for the first use, but for the second, it’s erasing valuable information about the issues existing in the current version.
fbdab103 3y ago
Could do what the FastAPI project decided to do - close all issues and open them as "Discussions". Low open issue count and hard to have a sense on what is/not working.
kelnos 3y ago
I resist telling open source developers how to run their projects, because I am one myself, and get annoyed when other people do that to me. But oof, if I were a user who spent some non-trivial time filing an issue & helping troubleshoot, or working on a fix or new feature and submitting a pull request, I'd be feeling pretty discouraged right now.
- jazdw 3y ago
  Most users spend trivial time filling issues however. Most bug reports are crap.
  - ozim 3y ago
    Well parent wrote about a user who took his time and put in effort. No one wants to loose those so it is sad for both sides.
  - xmodem 3y ago
    In my opinion, if a bug report is crap, it is perfectly acceptable to politely say so with a canned response and then close the issue a week later if better information is not forthcoming. Declaring 'issue bankruptcy' shows that you do not care about your users time and tells me that I should not trust your project.
- Biganon 3y ago
  The issues are closed, not lost. They can probably ask them again later if they are still pertinent
deleted 3y ago
[deleted]
yieldcrv 3y ago
zero interest rate phenomenon
- maxbond 3y ago
  Is this a meme post or is there a real connection here?
  - yieldcrv 3y ago
    continued fallout, the stress and lack of tolerance for continued support is likely related to the more difficult macroeconomic environment all we have are correlations though
px1999 3y ago
I love this, and wish other projects would follow suit and not be afraid to say "no" to people asking for changes/fixes. The obligations that the industry places on open source project maintained by unpaid volunteers are unfair and unrealistic. If someone actually cares about specific changes/PRs they should fork the library and implement or apply those appropriate patches/changes A "no" is IMO infinitely more useful than an indefinite "maybe" (what most projects do, because they are afraid to say no to anyone) when it comes to these things.
heisenbit 3y ago
The problem with this is that there are search functions for issues which default to a filter of open. So when I have an odd behavior and search for clues in the issue DB I would like to also see older not fixed and never will be fixe issues.
WesolyKubeczek 3y ago
A move somehow reminiscent of GNOME 2 move that prompted jwz to coin the “CADT” term. His essay seems to never get old.
darthrupert 3y ago
I don't understand why not all projects don't do this as regular maintenance. Old bug reports are almost always deadweight. Perhaps keep them in an archive if you must.
pronik 3y ago
While I don't think open issue are a problem, I very much prefer such events of bankruptcy to a slow death by a stalebot which happens quite often when the maintainers start to lack time or motivation.
JuanPosadas 3y ago
Why don't they just use the maintainer-never-looks-at-bugs + autoclose-for-inactivity-30-days like all the civilized repos?
nobodyandproud 3y ago
What steps are being taken to avoid a Perl 6/Rakudo-style misstep?
haburka 3y ago
There’s more discussion in this issue: https://github.com/lodash/lodash/issues/5719 https://github.com/lodash/lodash/issues/5719 Frankly I commend the author. If you’re maintaining one of the most used open source packages, I think it must be overwhelming to get so much feedback. Realistically a team of 4 people probably working full time could manage a package like that and it seems like it’s just one guys side project.
rkuykendall-com 3y ago
I think everyone in the comments here is missing the point. Lodash is a dead project and has not done a release for 3 years. All the PRs and issues were for a version of the codebase that has not existed for a long long time. There is no working version of the codebase anymore. I will be surprised if lodash ever comes back in any meaningful way.
omnibrain 3y ago
They tagged 363 issues with "issue bankruptcy" and closed them: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Aclosed+label%3A%22issue+bankruptcy%22 https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl... Same for 325 PRs: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed+label%3A%22issue+bankruptcy%22 https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...

240 points by omnibrain 3y ago

Relevant recent tweet from lodash's creator: https://x.com/jdalton/status/1701015897702572335?t=YLClO1zWazNXh3YkMilJYA&s=09 https://x.com/jdalton/status/1701015897702572335?t=YLClO1zWa...

bluefirebrand 3y ago

Lodash is a great library. It's something I wind up using a little bit of on almost every project I work on. However, as JavaScript has become better and better, I use Lodash less and less. Every time I catch myself using it, I make sure to go see if there's a built-in for what I'm trying to do. I also find myself commenting on PRs with links to "you don't need Lodash for this" quite often. I still hope this isn't a sign they are stepping away from the project.

darepublic 3y ago
It's definitely convenient but I think invariably I would prefer to just roll my own versions of its utils if it came down to it
- BoiledCabbage 3y ago
  Why?
  - kakadoodle 3y ago
    Maybe start explaining why not, and then ask why someone would? I think it would create a more interesting conversation.
  - 0000000000100 3y ago
    Less dependencies makes maintaining the project easier.
    - erik_seaberg 3y ago
      Popular libraries have been battle tested in prod, and my teammates probably have prior experience with them.
      - darepublic 3y ago
        There are more than a few popular js libs that are pretty trash IMO. Though I would not count lodash among them. Battle tested can often just mean teams use them for better or worse, and I can often see in the code how bad frameworks cause juniors to contort their solutions in all the wrong ways to make them adhere to a framework instead of untie the knot and do it the right way. Sometimes it is the framework being used incorrectly. The devs should invest time to learn the API better. But often it's better to just learn how to do the solution sans framework rather than add to the stack of bespoke APIs to learn. And junior devs can become dependent on frameworks for every little thing to the point where they will always reach for one even if the choices are poor
    - SkyPuncher 3y ago
      How? That’s more internal code with bugs.
      - sebastianz 3y ago
        Some internal code with bugs is way better than lots of external code with other people's bugs.
        SkyPuncher 3y ago
        Pretty much disagree on every front. Particularly for a major library. There's a very good chance those "other people" have thought about the problem they're trying to solve way more than you have.
        yakshaving_jgt 3y ago
        You don’t think this learned helplessness is depressing? Whether or not a team decides to own some portion of code is a complex topic. Sometimes it makes sense to leverage something external, and sometimes it makes sense to write it yourself. In my business, we had a [ostensibly senior] guy insist we use an external technology because it would be too hard for us to own that piece ourselves, despite it being a core part of the product. Technical due diligence on the external technology showed that it didn’t actually work as advertised. Six figure price tag and apparently millions invested for a thing that doesn’t work (and “doesn’t work” in this case meant “corrupted financial data”). Whether or not a team owns some technology is highly context dependent, and your comment comes across as reductive.
  - darepublic 3y ago
    Because the surface area of lodash is so large and I need just a small fraction of it. And when I do need it it's easy to make a simple transparent version of the needed until rather than invoke a mystical black box. I admit this is opinionated and I have managed to work with lodash and keep my mouth shut about it
    - BoiledCabbage 3y ago
      Thanks for sharing - I disagree with the approach, but understand it. Or rather, I feel that can work for individual coding, or possibly very small teams - but in the end I feel it usually works out to be unintentionally anti-team behavior. It trades off "I need to learn and understand this black box of behavior for instead I have this code that I know and can easily reason about". While for the entire rest of your team it went from "there is this common pattern that most of all 20 (or however many) of us know - and instead makes it 19 of us now need to learn this non-standard behavior/implementation, but at least one person knows well." Essentially everyone else has to learn more code, so that one person doesn't. Agreed it's usually not the most complex of code, but it's usually buggier and shifts to cost / burden to everyone else. The opposite of economies of scale and leveraging prior fixed costs of learning. But again, I don't know your situation and will readily admit my opinion above doesn't in anyway make it factually a better approach. Just my opinion on it same as yours.
      - rcme 3y ago
        It works perfectly fine. You just copy and paste the code you need. If someone else needs it, they search the code base first, which is normal in large code bases. There are tons of different libraries that provide deep equality checks for instance. When I work in a code base, I need to search for existing solutions in the code base before adding someone new. It doesn’t matter if the functionality is provided by a first or third part library.
    - xeromal 3y ago
      I'm not sure if you're aware but lodash has individual packages for each of their functions.
  - mostlylurks 3y ago
    Not super relevant for lodash in particular, but another reason for why someone might want to do this is dependency hell. At least with code you write yourself, you know that the author(s) won't keep changing the API (very common in the javascript ecosystem, unfortunately), forcing you to either waste time constantly changing your own code to match the newer APIs, or stick to a single version for a long time, which may become incompatible with newer versions of other dependencies, your build system, your language, your environment, etc, which will become an issue if you have something else that you want to update but that old version of the dependency doesn't support it. So in some cases it might be easier and more maintainable to just write your own version of whatever small feature of the dependency you might otherwise have used, but knowing when this will be the case is a skill of its own.
jauntywundrkind 3y ago
Very much agreed. The amount of mileage we get from using Spread (literally the ...) alone has been amazing. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Iteration helpers is shipping soon, that'll be a huge help (async iteration helpers will be delayed for a while). https://github.com/tc39/proposal-iterator-helpers https://github.com/tc39/proposal-iterator-helpers . In the olden days, I feel like the codebases I worked on needed to use .apply() multiple times a week, to figure out some creative way of invoking functions. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/apply https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... That's all gone now; I'd take even odds that 50% of my team knows .call and .apply. Chrome 117 is shipping Object.groupBy() and that's gonna be a huge help in eliminating a lot of the last places we end up using lodash. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/groupBy https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
throw1234651234 3y ago
I haven't used lodash or underscore.js since 8 years ago. I just don't see what it has that can't be accomplished easily with map / filter / find, etc.
- JuanPosadas 3y ago
  I wish some of you-might-not-need-lodash websites would include the approximate file size savings with each featured function. Some of them can be 5kb for a single function.

SeanAnderson 3y ago

I am so conflicted on this! On the one hand, I fucking love it. Who hasn't experienced a backlog grooming session where you know it's impossible to reach the end of the backlog and you just sort of go along with the process of scraping from the top. There's definitely something miserable about that feeling. On the other hand, it's not like the issues are gone, they're just tagged differently, and if everything is just tags and organization then why not go with the flow rather than exerting control in an attempt to achieve this pseudo-perfect empty issue list. There's gotta be benefit in keeping those notes around and visible, right? Sort of feels like deciding to throw something out of your house while deep in a cleaning spree even though your subconscious is (reasonably) nagging at you to hold onto it because you might need it in the future. On the whole I think I'm for it, though, if anything just for the cathartic release and presumed re-invigoration towards new issues.

etler 3y ago
For a bit more context, the creator is doing a full rewrite. I think it would probably have been cleaner to release the rewrite first, then close all the old issues as deprecated. You could isolate the rewrite branch issues with a version tag. Closing then while the new version isn't done may lead to contributers opening new issues on the old version without realizing that it is no longer supported. But he's not just ignoring the issues and leaving problems in the code base, the entire project is getting a refresh. https://twitter.com/jdalton/status/1571863497969119238 https://twitter.com/jdalton/status/1571863497969119238
- brailsafe 3y ago
  I like it, it's the "put everything in a giant mailbag, label it, and dump it in a storage locker" approach. If the issues are still relevant, they can be resurfaced.
  - ImPostingOnHN 3y ago
    "...and when resurfaced, they will be stuffed into the 4th mailbag for further 'resurfacing'"

vosper 3y ago

What is issue bankruptcy? Is it declaring that you don’t have the resources look at the issues? It seems much better to tag them like Lodash has done rather than let open issues pile up like many other low- or no-resource projects do.

klardotsh 3y ago
In IRL bankruptcy you declare you can't possibly pay back your creditors and lose "most" non-trivial assets as they're liquidated off to attempt to make a few pennies for those creditors as you rebuild your life from 0. Lodash just decided to rebuild from 0 - literally, actually, since it's a rewrite, but especially in the bug tracker sense of the word.
jowea 3y ago
Have you heard of email bankruptcy? When you empty your inbox unread and start over again.

pxue 3y ago

select all open issues, Tag: won't fix, close. Restart cycle.

romellem 3y ago

John-David Dalton, the lodash author, wrote [this last year][1]: > For the lodash rewrite I’m declaring tech debt bankruptcy. Starting from scratch with TypeScript and Rollup. No FP wrappers. That fad is over. RIP your co-workers if you introduced that headache into your codebase. Definitely not team or human friendly. Don’t know if he’s sticking to this 100% but seems pretty close. [1]: https://twitter.com/jdalton/status/1571863497969119238 https://twitter.com/jdalton/status/1571863497969119238

gorgoiler 3y ago
What were FP wrappers and what was the fad?
- stolenmerch 3y ago
  "Auto-curried function style (reversed arg) wrappers" https://twitter.com/jdalton/status/1571870137690591236 https://twitter.com/jdalton/status/1571870137690591236
  - legulere 3y ago
    And what is that?
    - janehdoch 3y ago
      [flagged]
    - gorgoiler 3y ago
      Specifically I don’t know, though I do know what currying is. This auto-currying thing sounds like a reaction against some parts of JavaScript where you can get burned by default arguments. A curried function is like a partial application for each argument. If mul:=(a,b)=>a*b then currying would be being able to say double:=mul(2). Currying everything and requiring all function calls to have one parameter per call — six:=mul(2)(3) — might have some benefit in avoiding bugs. Generally speaking though my hunch is that the lodash author grew tired of the project’s focus on meta programming: noodling around with JavaScript using programming paradigms that hinder rather than help its users. Dropping the noodling and focusing on features is a “back to basics” moment, if you will.

beebeepka 3y ago

I never liked lodash, even when when it was new. These days I just laugh when people tell how great it is. Useful? Sure. But if you care about performance and simplicity, just spend a day or two writing your own versions of the things that you need. Or, if rolling home made is not to your liking, go with ramda. Edit: downvote vall you want but at least have a look at lodash internals just in case. What an overcomplicated mess. It's old, really old.

K0balt 3y ago
He’s rewriting from scratch in typescript.
SparkyMcUnicorn 3y ago
Looking at the internals is often why I choose to use it. It catches edge cases I might not think of, and the performance tradeoffs have been negligible to none. I don't use it for everything, and definitely try to use native and/or narrower scope methods when it makes sense, but it's saved me a lot of time and headache throughout the years.
paulgb 3y ago
Are there functions where the performance is significantly worse than what you could write on your own? Not a rhetorical question. I don’t use lodash but as a primarily non-JS dev I’ve referred to the source some times when I’m writing JS as a reference for the idiomatic way to do simple things. I’ve found some weird things, like isEmpty is technically O(n), but this turns out to be a limitation of JavaScript rather than a lodash issue.
- eyphka 3y ago
  There are a couple of weird things in my experience, like the old implementation of zip, but by and large it was mostly either restrictions of js itself or browser implementations of js. Lodash has and still is a good standard / reference for these simple operations imo.
- mediumdeviation 3y ago

CodeWriter23 3y ago

Everyone gets a feature!

pscanf 3y ago

Well done! Looking at the first few PRs in the list, you can see things like: - Adding a word in a comment. - Adding config files to self-promote dev services. - Switching from using var to let. - Changing well-established behaviours of core functions. - Removing semicolons. - ... I'm sure most of those were opened with good intentions of improving the library, but at some point for the maintainer they just become spam (or worse, a growing burden that makes you feel guiltier and guiltier for not giving it attention). Celebrities hire bodyguards and fly first class (or private) to avoid the constant stream of attention and keep sane. I wonder what measures could be taken by celebrity OSS projects.

EdwardDiego 3y ago
> Switching from using var to let. One particular GH user submitted multiple PRs doing only that. Across multiple JS projects... ...feels like GH profile padding.
- fmajid 3y ago
  Not so much padding the profile as making the github contribution graph more solidly green.
Null-Set 3y ago
There was a trend for a while for people to open trivial PRs against popular projects, I believe in an attempt to pad their resumes.
- kynetic 3y ago
  This is still a trend unfortunately.
- gochi 3y ago
  They can keep padding their resume if it means little fixes actually happen. Even typos and little translations, they affect the general reputability of the software. Sounds like a fair trade, especially as most hiring companies can just look at PRs and see what was actually changed very easily.

erik_seaberg 3y ago

As jwz put it > This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch—and the new maintainer can’t be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.

hackermatic 3y ago
It's like that with security findings, too.
neilv 3y ago
And a variation on that: the issue was reported against one major release, but a new major release (just incremental changes, not rewrite) is coming out, so close all issues against the old release, because the problem might no longer exist.
- RaisingSpear 3y ago
  Or simply: > report issue > issue is automatically closed 6 months later due to lack of activity ...with absolutely no change to or comment on the issue.
jauntywundrkind 3y ago
Make a PR with some tests that should pass, but are instead marked skipped. That way when the rebuild comes around, there's an easy path for the rebuild to see how it's doing, see if things are at all improved. If you care about it, you should put a test on it.
- erik_seaberg 3y ago
  I’m probably not enough of an expert on their code to write that unit test. And I don’t have much faith in a team who blindly closes bugs to unskip tests and upgrade them to the new API.
- 3y ago

smitop 3y ago

The bigger news is that Lodash is migrating from Node.js to Bun: https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d7b813bed96b35b5abf15#diff-9ef15c0955375fd602c4e30fb95794a5d5b33909fe57f0e79127afa10ce578f3 https://github.com/lodash/lodash/commit/97d4a2fe193a66f5f96d...

firtoz 3y ago
Woah. I was starting to get excited about migrating my packages to Bun, but hesitating because I was afraid of compatibility or whether Bun is really here to stay or not - I have been slightly burnt by "Modern Yarn"; but honestly, seeing lodash make the leap makes me want to consider it more seriously now.
- steve_adams_86 3y ago
  I’m a yarn burn victim as well, and it has made me a lot more apprehensive about fundamental decisions like these. They seem so promising and your research seems to check all/most of the boxes… Then you get Yarn 2/3
  - dheerajvs 3y ago
    What's wrong with yarn 2+ (berry)?
    - steve_adams_86 3y ago
      My issue is the substantial shift in the API, major bugs and poor documentation in the initial workspaces implementation, then more subjectively, I didn’t like the PnP solution though it seems to work more reliably now. I worked on a very large monorepo that was using yarn and the headaches that occurred from migrating to workspaces and newer versions of Yarn were absolutely brutal. In many ways things were better and other package managers technically couldn’t offer the same features, but there’s a reason packages like Lerna/Nx/Turborepo were used to accomplish similar things despite it being possible with yarn. It was extremely cumbersome, didn’t work intuitively with TypeScript, felt like a house of cards at times, etc. I understand it’s better now, but getting hit by that transition was a burn if I ever saw one.

Supply5411 3y ago

Issue bankruptcy is real. Speaking from personal experience, at some point maintaining OSS is incompatible with living in the real world. The work is free and often thankless (but not always). The problems are complex and compete with real world responsibilities, like work, family, rest. People get pissy and regularly want to argue with you or read the docs for them. It also carries enormous responsibility if your OSS is popular. I am anticipating a huge collapse in the OSS ecosystem as the people who drive them say "fuck it" and walk away for more important things.

eternityforest 3y ago
That I can understand. These days I'm almost starting to think of nontrivial personal projects as more an addiction or self harm than real projects. The OSS ecosystem is insanely inefficient though. There's lodash, underscore, and plenty of others. They don't all need to exist. There's also lots of libraries that only do one thing, which are mostly a subset of something like this. Most of this stuff will be used with minifiers and tree shaking, and unused features will be removed, we don't need lightweight libraries when the heavy ones are easily optimized and mostly made of separate parts, so the dev effort mostly scales linearly. I think OSS has plenty of manpower, even if everyone decided to only spend a quarter of the time they currently spend, if it weren't for the fact programmers like elegance and simplicity more than anything, and constantly want to rewrite to make things just a little bit better.

xwdv 3y ago

I wonder if for some very popular open source libraries, charging a small fee to report an issue might be some kind of viable business model, or at least a way to prevent too many issues. You might say this will result in people not reporting legitimate issues, but as we can see in this case it’s not the end of the world.

JuanPosadas 3y ago
I think it would be cool if any user could add bounties to any issues and the maintainers could sort by highest bounty and then complete those first.

monksy 3y ago

I wonder if this would be a thing if everyone who created an issue had to reproduce it via a test.

zadokshi 3y ago

Let the one who throws the first stone at the “closed / won’t fix” manager, themselves be the person that has to fix it.

hedora 3y ago

I hadn’t heard of lodash. From Wikipedia: > Lodash is a JavaScript library that helps programmers write more concise and maintainable JavaScript. I love the sweet, sweet irony! (“Blind leading the blind”, and all that.)

earthboundkid 3y ago
There was a time when it (or underscore.js, its predecessor) was a useful collection of Array methods, but since then almost everything of value in underscore has been added to the Array prototype itself, so I don’t really see a point in using it anymore. The devs know this too, so now they’re just bored and rewriting for no particular reason.

panic 3y ago

Issue trackers have two overlaid uses. First, they’re a way for maintainers to keep track of work they have to do, and second, they’re a way for the larger community (including users) to keep track of defects in the software. Declaring “issue bankruptcy” makes sense for the first use, but for the second, it’s erasing valuable information about the issues existing in the current version.

fbdab103 3y ago

Could do what the FastAPI project decided to do - close all issues and open them as "Discussions". Low open issue count and hard to have a sense on what is/not working.

kelnos 3y ago

I resist telling open source developers how to run their projects, because I am one myself, and get annoyed when other people do that to me. But oof, if I were a user who spent some non-trivial time filing an issue & helping troubleshoot, or working on a fix or new feature and submitting a pull request, I'd be feeling pretty discouraged right now.

jazdw 3y ago
Most users spend trivial time filling issues however. Most bug reports are crap.
- ozim 3y ago
  Well parent wrote about a user who took his time and put in effort. No one wants to loose those so it is sad for both sides.
- xmodem 3y ago
  In my opinion, if a bug report is crap, it is perfectly acceptable to politely say so with a canned response and then close the issue a week later if better information is not forthcoming. Declaring 'issue bankruptcy' shows that you do not care about your users time and tells me that I should not trust your project.
Biganon 3y ago
The issues are closed, not lost. They can probably ask them again later if they are still pertinent

deleted 3y ago

[deleted]

yieldcrv 3y ago

zero interest rate phenomenon

maxbond 3y ago
Is this a meme post or is there a real connection here?
- yieldcrv 3y ago
  continued fallout, the stress and lack of tolerance for continued support is likely related to the more difficult macroeconomic environment all we have are correlations though

px1999 3y ago

I love this, and wish other projects would follow suit and not be afraid to say "no" to people asking for changes/fixes. The obligations that the industry places on open source project maintained by unpaid volunteers are unfair and unrealistic. If someone actually cares about specific changes/PRs they should fork the library and implement or apply those appropriate patches/changes A "no" is IMO infinitely more useful than an indefinite "maybe" (what most projects do, because they are afraid to say no to anyone) when it comes to these things.

heisenbit 3y ago

The problem with this is that there are search functions for issues which default to a filter of open. So when I have an odd behavior and search for clues in the issue DB I would like to also see older not fixed and never will be fixe issues.

WesolyKubeczek 3y ago

A move somehow reminiscent of GNOME 2 move that prompted jwz to coin the “CADT” term. His essay seems to never get old.

darthrupert 3y ago

I don't understand why not all projects don't do this as regular maintenance. Old bug reports are almost always deadweight. Perhaps keep them in an archive if you must.

pronik 3y ago

While I don't think open issue are a problem, I very much prefer such events of bankruptcy to a slow death by a stalebot which happens quite often when the maintainers start to lack time or motivation.

JuanPosadas 3y ago

Why don't they just use the maintainer-never-looks-at-bugs + autoclose-for-inactivity-30-days like all the civilized repos?

nobodyandproud 3y ago

What steps are being taken to avoid a Perl 6/Rakudo-style misstep?

haburka 3y ago

There’s more discussion in this issue: https://github.com/lodash/lodash/issues/5719 https://github.com/lodash/lodash/issues/5719 Frankly I commend the author. If you’re maintaining one of the most used open source packages, I think it must be overwhelming to get so much feedback. Realistically a team of 4 people probably working full time could manage a package like that and it seems like it’s just one guys side project.

rkuykendall-com 3y ago

I think everyone in the comments here is missing the point. Lodash is a dead project and has not done a release for 3 years. All the PRs and issues were for a version of the codebase that has not existed for a long long time. There is no working version of the codebase anymore. I will be surprised if lodash ever comes back in any meaningful way.

omnibrain 3y ago

They tagged 363 issues with "issue bankruptcy" and closed them: https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Aclosed+label%3A%22issue+bankruptcy%22 https://github.com/lodash/lodash/issues?q=is%3Aissue+is%3Acl... Same for 325 PRs: https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed+label%3A%22issue+bankruptcy%22 https://github.com/lodash/lodash/pulls?q=is%3Apr+is%3Aclosed...