📰 ESlint Rules

This week, the ESLint rules that I’ve been working on for … let’s just say it’s been a long time, are finally out of beta.

A few months ago, I cleaned up the remaining rule implementations that performed their own AST traversals and, at that point, all that remained was to remove rules that had ‘official’ equivalents and to complete the docs. Well, I finished those tasks this week, so the packages are now actually released.

eslint-plugin-rxjs contains RxJS-related rules, eslint-plugin-rxjs-angular contains a few opinionated Angular/RxJS-related and eslint-plugin-etc contains some general-purpose, TypeScript rules.

In addition to those, I’ve started thinking about some lint rules for React.

I have a bunch of ideas on how TypeScript could be leveraged to perform some React-specific static analysis that wouldn’t be possible in a conventional ESLint rule. ATM, there’s a package - eslint-plugin-react-etc - that contains a single JavaScript or TypeScript rule for useEffect calls that could/should be replaced with useMemo calls. I anticipate adding more, when I have the time.

Also this week, I’ve published a blog post about how error-reporting differs between RxJS versions and how it’s going to work in version 7. You can read about it here.

Regarding RxJS and version 7, most of what has transpired this week has been type-related. There are several PRs that use variadic tuples to reduce the number of overload signatures. However, there’s a stumbling block that appears to be a TypeScript problem: TypeScript isn’t effecting an error when it ought to.

If you’re curious, you can check out this TypeScript playground snippet, but I’ll understand completely if you just want to look the other way. 😬