Hacker News Reader

Comment by lavax | 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.

View on HN

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

Reply on news.ycombinator.com