I’m so confused 😅 we’ve been transparently maintaining @angular-eslint with @mgechev for a long time now... why are you reinventing a builder here?

I mentioned this on Twitter, but let me replay here as well 🙂

We want to make the ESLint builder the default one and ship it as part of the devkit, instead of adding a dependency.

Since it's 80 lines of code, it doesn't seem like a wasted opportunity for code reuse. At the same time, we'll be using @typescript-eslint and @angular-eslint to get a ruleset with the largest overlap possible to what we currently offer in new projects.

Twitter is not the right medium to be able to write up my thoughts, so I will write long-form here.

I have spent a good amount of time today reflecting and have the following concerns with the actions taken:

Technical

We want to make the ESLint builder the default one and ship it as part of the devkit, instead of adding a dependency.

• Which dependency are you referring to? I think there are multiple options here: An end user's Angular CLI workspace could depend on @angular-eslint/builder, or @angular-devkit could. In the latter case the user would not be aware of the dependency and it would not take up space in their package.json if that is the concern being cited?

• It is reductive to present this as a matter of lines of code. The builder in @angular-eslint is built and integration tested with all the other @angular-eslint packages on every commit. By creating a new implementation you are forgoing that large maintainability and quality control upside (for the as yet unclear benefit highlighted by the first bullet)

• By doing this with the builder, you are also indirectly declaring you have no plans to use the schematics I have already created in @angular-eslint either (because they cross-reference). These again benefit from being built and maintained together and I don't understand the technical motivation to dismiss that.

• Angular and devkit releases do not happen as frequently as @angular-eslint could release, so that is another downside of moving implementation details to devkit.

From a technical perspective the real question is: why not have devkit wrap @angular-eslint/builder?

Personal

Over and above the technical concerns, I do still find this to be a somewhat cold move which does not show consideration or empathy for me as a long-term community contributor who has diligently dedicated myself to solving these problems for this ecosystem. The likes and responses to my tweet from other prolific open-source contributors show that I am likely not alone in my conclusions.

When I left the ESLint Team to create and focus exclusively on typescript-eslint, I actually originally did so because I wanted to be able to use ESLint on my Angular projects. Angular is therefore a key factor in the entire TypeScript + ESLint story! As such, it's now the realization of a multi-year effort on my part to have Angular and ESLint working effectively together. You do know this history and personal investment, Minko, because I explained it to you on a call last year.

When it became clear TSLint was going away completely and even the Angular CLI would need to find a solution for migrating, I put a lot of effort into figuring out all the tricky bits of how rules should be created and tested (so that other contributors could just focus on writing them using pre-made utils), how Angular templates could be parsed and linted by ESLint, and how users would migrate from TSLint to ESLint within their Angular CLI workspaces.

I have done all of this transparently in public and tried to encourage others to help. That has not really materialized and so I have an order of magnitude more contributions than anyone else in the community over the last year.

In summary then, from my perspective you were aware that I have spent many hours of unsupported, unpaid personal time writing docs, creating and iterating on a builder and schematics to allow Angular CLI users to migrate from TSLint to ESLint. You nevertheless did not think I deserved a quick heads up that this partial alternative was coming and that you would be actively choosing to not use a significant portion my work (the number of lines not written in this builder PR are as important as the ones that are - this is a copy of my latest work, but there were plenty of iterations before this and you are benefitting from that time investment with your "80 lines of code").

The hardest thing to take of all is: you knew you were going to do this - you therefore knew I was spending valuable time on something that in your mind would not be used for the ultimate solution for Angular CLI users. You could have reached out at any time, and honestly it doesn't feel great that you would let me waste my time like that.

Finally, I feel you further doubled down on the lack of empathy you showed when you responded to it all on Twitter by saying that I "misinterpreted" the actions. This acts to remove any culpability in the actions themselves - it acts to say "the actions were objective and pure, your interpretation is simply incorrect".

I would definitely like to hear from you on the technical points, as so far the justification is somewhat unclear. As for the personal points, I am lucky and grateful to have a lot more privilege than most - this matters in two ways (1) I will dust myself off and be fine off the back of this (2) I felt it was important that I transparently shared how I felt when faced with actions I believe would negatively impact anyone in this community given the same circumstances.

Here's to building the best community together we can 🤝

Sorry about the misunderstanding. We were able to reconnect with James and are happy to have his help ongoing.

Closing in favor of the community builder https://github.com/angular-eslint/angular-eslint

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}