ESLint Plugin?

[seanblonien]

Is there a reason why this VSCde plugin isn't just made into an ESLint plugin?

"48 automated refactorings, cleanups and actions for JavaScript and TypeScript."

Cleaning up JavaScript and TypeScript with automated fixes is quite literally the whole point of ESLint, so I was curious to discuss why this couldn't be made into a plugin/ruleset.

I loved this article about replacing nested ifs with guard clauses which is how I found this extension.

Benefits of doing this:

• allows CLI usage in any node environment
• decouples from VSCode, while also integrating with VSCode's built-in eslint support
• allows applying these rules to other IDEs
• allows running these rules on build servers
• easier rule configuration for consumers of this refactor tool with eslint rule config. this also allows for centralizing all JS/TS code rules to be just within eslint instead of eslint + VSCode

Also, the eslint community is huge. It is already the defacto standard for auto-fixes, refactors, and linting JS/TS. I am curious why being outside of that ecosystem makes any sense if you want to be truly open source and help the community.

[lgrammel]

Hi Sean,

Thanks for your interest and the suggestion!

I agree with the benefits you mentioned, and I have thought deeply about this, especially in the initial phase of the project. There are both technical and non-technical reasons for the current direction of P42:

• The goal of P42 is to be a programming assistant, not to be a linter. While P42 suggests improvements similar to lint rules, the overall scope is much larger (and already visible through refactorings that are not lint rules). You will see more in this direction in the coming months. Integrating into ESLint would severely limit the goal and scope of P42.
• The various technical parts of P42 (core matcher & transformation engine, reprinting, testing) are different from ESLint. I studied the ESLint implementation, implemented an improved version, and rewrote it several times in newer, further enhanced versions. P42 code actions are now much faster, easier to write, and easier to test (compared to ESLint). But unfortunately, the result is incompatible with the ESLint engine, and using ESLint as the base for P42 would be a big step back in performance, capabilities, and maintainability.

Maybe you're asking yourself, "How is P42 (programming assistant) different from a linter?" Here is my current take on the key differences:

• Rule complexity: A linter looks at syntactic rules (e.g., semicolons) and some semantic rules (e.g., usage of var/let/const). P42 leaves syntactic rules to a pretty-printer (e.g., Prettier) and contains simple and more complex semantic rules.
• Rule scope: A linter does local checks in a single file. P42 could make cross-file suggestions (e.g., move functions).
• Rule hardness: A linter has mostly hard rules (error/warn). P42 provides optional suggestions in a non-obtrusive way (hints).
• Rule auto-fix: A linter has many rules without auto-fixing that require developers to figure out and make the change manually. P42 always provides actionable auto-fixes.
• Auto-fix correctness: A linter aims only to make correct changes, limiting the availability of auto-fixes. P42 evaluates the safety of an auto-fix, informs the developer about potential issues, and leaves the decision to the developer.
• Analyzed code: A linter analyzes the local context of a rule in a single file. P42 will eventually explore the full program context and the used libraries, leading to more sophisticated and precise suggestions.

Making P42 open source is a potential avenue I'm still considering. I love open source and have published many open source projects in the past, mainly before the age of GitHub.

Considering the funding problem of open source and my desire to work on P42 full time, I've so far concluded that I can give back most to the open-source community by making the use of P42 for open source and in VSCode free, but keep the code itself closed source for the time being. A cloud version called P42+ for GitHub is free for open-source and paid-for for private commercial projects.

I would love to hear your thoughts on the open sourcing of P42. In an ideal world, this is something that I'd want to do - but I can't see how to make it work financially, and I think the benefits for both the community and me are higher if I keep it closed-source.

Best,

Lars

[seanblonien]

Thank you for the very detailed response!

All of these reasons make sense given that context and the vision of your tool you have. The programming assistant purpose of the tool and the perceived technical limitations with a tool like eslint does better explain why you want to be outside of that ecosystem.

But let me challenge you on these points you make:

• Rule complexity - it is interesting to see how this is becoming less and less true with more complicated rules coming out, like those from eslint-plugin-sonarjs. rules theoretically can be made to be as complex as you'd like
• Rule scope - this, like above, is also less and less true, as eslint-plugin-import implements rules that check multiple files with their no-cycle rule.
• Rule hardness - you're definitely right about this limitation. although from that original article I read where I found this, I don't really see a difference between a hint and warning. the use case doesn't seem that large to have more than just off/warn/error at least to me
• Rule auto-fix - eslint rules can have auto-fix. some of them don't, even the well-known and popular ones, but taking your inline-return for example, that rule exists as prefer-immeidate-return in eslint-plugin-sonarjs, which can be auto-fixed. For convert-if-else-to-guard-clause, that'd likely be more of a challenge, but I'd bet it's possible
• Auto-fix correctness: - hm yes this seems to be a better point, as there is no easy way (as far as I currently can tell) to disable auto-fixing for a specific rule (although there does seem to be workarounds)
• Analyzed code - as shown by eslint-plugin-import, this is simply not a limitation of eslint. you can analyze any and all connected code. I think you could easily make sophisticated rules in eslint, even if most rules aren't generally known to be sophisticated

You keep mentioning "a linter..." as if eslint is only a "generic linter" and linters are only limited to doing certain things, but I think that's a bad perspective to have about the eslint and its ecosystem/plugins.

Yes, eslint is originally a linter (because it started out as such), but now it is definitely a formatter (i.e. prettier plugin) and static code analyzer (eslint-plugin-sonarjs, eslint-plugin-unused-imports, eslint-plugin-react, and @typescript-eslint/eslint-plugin). I imagine this is just a shift in perspective on how you think about eslint - it is capable of more than "generic linting" with its plugins and I do imagine most of your rules could be re-written in its eco-system.

Also, just a thought: reach out to one of the large maintainers of one of the eslint-plugin packages and see if they have advice if these complicated rules could be made into eslint rules, I'm sure someone could speak to it.

If I have time one day, I may attempt to write an eslint rule for convert-if-else-to-guard-clause. I should really eat the words I'm spewing cause I've actually never written a complicated eslint rule from scratch. If I do, I would probably have even more context on how doable these more complicated "programming assistant" rules would really be.

[seanblonien]

Forgot to address the last point - yes what I am suggesting (fully converting all of these rules into eslint rules in the open-source eslint ecosystem) does not address your funding problem of P42 at all. So it makes sense to keep your current system if keeping it custom/closed-source better addresses your funding problem.

BUT, if you're already making it free for personal use, and (in my experience) commercial projects may abuse your licenses of it anyways, if your funding problem still exists even while it's closed source after some time, I'd recommend moving over to eslint ecosystem for a much larger adoption and growth of this as a programming assistant tool.

Also thank you for the great discussion, I still fully respect what y'all do 💯

[lgrammel]

Thanks, Sean. I agree with your points on ESLint, and I am using ESLint in my projects.

However, even now, P42 has elements from different kinds of tools and gets perceived in different ways:

• some see it as a linting tool because of the suggestions
• some see it as a refactoring tool because of inline variable, extract variable, etc.
• some see it as a codemod tool because of the bulk refactorings
• some see it as a code action tool (like Webstorm) because of the additional actions it offers on specific code segments

As a result, people often suggested that I take P42 apart and move its parts into other tools, e.g., ESLint, other refactoring tools, etc. While this is correct in a way, it also misses the bigger picture.

A unified system with attributes like refactoring safety evaluation and non-intrusive UX is essential for the features that I plan to build. Taking P42 apart would effectively prevent me from implementing what I hope to be genuine innovations. P42 is still in its initial phase, so this might be hard to see at this point. I think it'll become more apparent once more advanced features become available.