Hacker News Reader

I try to focus on the issues rather than individuals, but the root of the problems in the listed eslint plugin libraries points to ljharb.

If you do some simple digging into these libraries, you will find that these types of commits are quite common within them.

https://github.com/jsx-eslint/eslint-plugin-react/commit/e1d...

https://github.com/jsx-eslint/jsx-ast-utils/commit/bad51d062...

https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/commit/...

He would rather see the download count of these polyfill libraries https://github.com/ljharb/ljharb#projects-i-maintain increase, compared to assessing the health of the JavaScript ecosystem.

ljharb is an extremely interesting person. There’s no doubting the positive impact he’s had on the OSS community and the work he’s done.

However, there are some things he does that are incomprehensible.

For example, Enzyme. Over three years ago this issue was opened for Enzyme on React 17: https://github.com/enzymejs/enzyme/issues/2429

Nothing moved for a while, and I think he said something along the lines of “if you want React 17 support, stop complaining and help”. So the community got involved. There are multiple PRs adding React 17 support. Many unofficial React 17 adapters. A lot of people have put a lot of work into this, ensuring compatibility, coverage etc. Yet to this day, none of them have been merged. Eg https://github.com/enzymejs/enzyme/pull/2564

Given the amount of time that has passed, and the work the community has put in, something is amiss. It feels like he’s now intentionally avoiding React 17+ support. But why? I don’t understand why someone would ask for help then ignore the help when it comes in. That isn’t much better than the swathe of rude/entitled comments he was getting on the issue before he locked it.

I ended up migrating to RTL, but this made many of my tests more complicated (especially compared to shallow rendering).

I'd guess the issue with that project is that it is mostly a single person effort and if that person is busy with other projects/repos/real life, they might not have the bandwidth to keep-up with the review, loose interest or maybe did not notice the PR update in the stream of incoming requests.

I guess the community (if there is any) can request to have more maintainers added to the repository to share the burden, else you still have the option to fork the repo and publish it under a different name.

I get being busy. But it’s been three years, and he keeps saying the project isn’t dead, so he hasn’t lost interest. Also, he asked for help then largely ignored the help and/or started bike shedding the PRs. He’s 100% across everything that happens in the repo, investing a lot of time replying to every comment immediately.

I’m pretty sure people offered to become maintainers and he declined. Forking has its own set of problems, but yeah you’re right, this is at least a possibility.

RTL is more flexible and arguably puts developers in the situation where they have to write better more user centric tests.

The complexity for me is around events which I imagine is somewhat common, that said in think it’s fair better and more durable than enzyme

Ljharb is harmful to the ECMAScript community

I'm thankful for his work, but I do agree, this polyfill madness has to stop.

I am _appreciative_ that people like him exist, because -- personal feelings aside -- we do need people who have his level of dedication in the open source space.

My only interactions with ljharb have been in TC39. More often than not when looking at issues he's active in, I find myself wanting a level of maturity and thoughtfulness that just isn't there.

His contributions are neither novel or very compelling. He's more of an open-source bureaucrat than an engineer or a developer, yet he is currently steering several major TC39 proposals. I've seen him shutdown or sidetrack valid input and criticisms in all of them. The vibes I get from his behavior are akin to him being a member of "the cool kid club" -- wanting to maintain that ingroup/outgroup boundary very tightly.

He really should just get out of the standards/committee space entirely for the time being, and get some coaching on leadership skills before reentering. I realize this is super negative. Still on the ropes whether or not this feedback belongs in the public space.

He's frequently on a powertrip and confidently wrong about so many things. For instance he's one of the people who perpetuate the "Javascript is fast and you don't need to optimize anything" falsehood. No wonder he's bringing in 100 polyfills into everyone's project. He thinks JS is C.

Insanity. In projects where I have full technical control I don’t use eslint anyway, it creates a massive load of work for negligible (if any) gain. Typescript finds the important issues, prettier fixes formatting; linters just create giant swathes of useless busywork.

I think your description of linting can be true, but not necessarily for every eslint configuration. I feel that I've landed on configs that feel useful to myself and the rest of the devs in the team. Even with a rule set that contains many rules that can look nit picky at first glance, no one complains since they are auto fixable, and fixing is a part of a commit hook.

There are a handful of rules that are nice to have in a TypeScript project to make sure devs don't do things that break type safety. Plus some that avoids mistakes from slipping through (even though the code is reviewed).

One thing I've found super useful is to have @typescript-eslint/ban-ts-comment enabled, but configured so that you can still use @ts-expect-error and the others as long as you provide a comment when doing so. This is so nice when doing code reviews, either someone has provided a very good reason for the exception, or it is clear that the same result could have been achieved with a better approach. Same goes for disabling eslint rules inline in a file, also allowed if commented. I feel that this is a very good compromise between being strict with linting, but also not letting linting get in the way.

Yeah there is like one rule that I often try to fix, the “no non-null assertions” rule (some.property!), because it often leads to bugs. I kind of wish you could just disable non-null assertions at the compiler level really. Maybe strict mode should do that.

I can’t think of any other lint rules I find valuable. For the giant mass of node_modules you need to run eslint, I think its cost-benefit is pretty darn terrible.

> massive load of work for negligible (if any) gain

If you coded alone for 10 years and then add a strict linting config you're going to have a really bad time.

If you actually follow the advice a linter gives you, you come up a 10x better developer.

Of course not all lint rules are created equal, but some are arguably existential.

I’ve done that, and I’ve coded on projects with big teams, with and without linters, for way longer than that, with multiple languages. Linters have never contributed anything close to what a half decent type system does to a project.

Types, tests, lints are all complementary. Your comparison is meaningless. The fact that you'd even compare the two shows how much your experience with linters is worth.

"I don't wear a helmet because I can just drive slowly"

"I can eat this 8-patty burger because I'm going for a run later"

You know, it's heresy to say, but if there was some kind of analytics or reporting done by the plugin we could know for sure that no node v4 users are out there on it and upgrade the deps and be done with the whole argument.

> But regardless, no one is required to stick to a particular way of creating open source software, so the one benefit here is that you are free to fork the library (assuming its license allows for that) to remove some backwards compatibility that isn't relevant to you.

I think that's the most important takeaway here. The library author decided not to make breaking changes and to keep compatibility wherever he can. I don't think that's a requirement many people have (not to this level, anyway), but it's not unreasonable either.

No project is required to use or accept his code. People want qs, resolve, and nvm.sh, and this one person is willing to provide it to everyone for free.

I don't care if he refuses suggestions because of "breaking changes" or because "they don't spark joy". It's his project, you can disagree with him all you want, but you can't complain that the free work he's doing isn't to your liking.

I think it's telling that a lot of people are willing to argue with the maintainer but very few people are willing to step up to provide and maintain a better fork.

Is there not a config for minimum supported JS version? That would appease everyone, while maintaining backwards compatibility.

Docs should show the recommended version (modern) and show what options are available to go deeper.

Obviously adding those settings for every pollyfill in non-trivial, but burdening everyone with every pollyfill ever is also suboptimal. If anything, this would make cleanup easier going forward since it would all be classified

There is an "engine"!entry in package.json, and a package manager should be smart enough to not upgrade past what it can. But people tend to not use that sort of dependency flexibility and use lock files…