Repository Linting Tool

[thatsamsonkid]

Wanted to discuss what we should do in terms of linting. @ashley-hunter brought up another good point in #447 issue as well. I really like biome and I definitely think it's the future but a part of me felt like we might have moved over to it a bit too early because like ashley mentioned it doesn't have angular template linting, custom rules and I think ben had added oxlint to support something else biome wasn't quite supporting yet either (I might be wrong here).

But in any case I feel like we should address this. I would maybe even consider moving back to ESLint unless biome has made significant strides since it was last introduced into the repo. But we should definitely get this sorted. But wanted to hear what the rest of you think.

[goetzrobin]

@benpsnyder curious to hear your thoughts on this. I definitely see your point @thatsamsonkid. Happy to discuss trade offs!

[ajitzero]

+1. I've seen the same issues trying to use biome exclusively. Apart from linting, the formatter doesn't support the @- if/for/let syntax either so I've moved back to Prettier in my own projects.

[ajitzero]

One more thing! Biome doesn't fully support HTML yet. It's officially marked as "In progress" for parsing/formatting and "Not in progress" for linting. I think we should move back to Prettier + ES Lint for the time being.

This is an existing issue for others like Vue, Svelte, Astro, etc.

[ashley-hunter]

Yes, I too think Biome is an incredible project and the speed is unparalleled.

If this was a React project I think the tools would be very similar in capability, but with Angular we are missing template linting, as well as all the Angular specific TypeScript rules. As @ajitzero has mentioned formatting support for control flow in templates also seems missing.

I guess it depends on whether the speed justifies the trade offs.

Regardless, I think we should pick one and remove the other entirely to avoid any confusion.

[benpsnyder]

I use biome and oxc AND eslint in my projects in different ways. I hope, in the near future, I can consolidate to just biome and oxc.

[ashley-hunter]

I guess we need to weigh up the pros and cons - there is no doubt that Biome/OXC are fantastic tools and are making great strides, but we need to evaluate them in their current state, and in the context of an open source library making as easy as possible for people to contribute.

The one thing Biome and Oxc are head and shoulders above ESLint and Prettier is speed - speed is always nice, but it should not come at the expense of code quality or adding friction for new contributors.

Using Biome, Oxc and ESLint in one project seems like a lot, but to me this illustrates that if they can't be used on their own, they aren't quite ready yet - at least in Angular projects. It also seems like there could end up being conflicting rules etc..
And having to run ESLint as well as the others kind of negates some the speed benefit of Biome/OXC.

We need to think about this from the perspective of a new contributor. As it stands, 90%+ of Angular developers will have ESLint plugin installed in their editors already and be very familiar with it, and certainly a large portion of them will also be using prettier. With just those tools required, someone can open the project and will likely have everything they need without any need to install new plugins or perform additional setup. There is already a lot to get your head around when diving into a new project, if things are familiar that is one less hurdle for contributors.

Another thing to think about is actually running the tasks. Right now our package.json looks like this:

"lint-publishable": "nx run-many --target=lint --projects=tag:scope:core,tag:scope:brain,tag:scope:helm,tag:scope:cli",
"lint-fix-publishable": "nx run-many --target=lint --projects=tag:scope:core,tag:scope:brain,tag:scope:helm,tag:scope:cli --fix",
"ci.format-sort": "biome ci --formatter-enabled=true --organize-imports-enabled=true --linter-enabled=false **/*",
"ci.lint-baby": "bunx --bun oxlint -c .oxlintrc.json --promise-plugin --import-plugin -D correctness -D perf -D eqeqeq --deny-warnings",
"ci.lint": "biome ci --formatter-enabled=false --organize-imports-enabled=false --linter-enabled=true ./* **/*",
"ox.lint": "oxlint --deny-warnings",
"biome.format": "biome check --formatter-enabled=true --organize-imports-enabled=true --linter-enabled=false --write {apps,libs}",
"biome.lint": "biome check --apply {apps,libs}",
"oxide.lint": "bunx --bun oxlint {apps,libs}",
"prettify": "prettier --write .",

This is in a confusing state, and it really isn't obvious what a developer is supposed to run to verify/fix their code. Really this should be as simple as:

"lint": "nx run-many --target=lint --parallel",
"format": "nx format --write"

Even with Biome supporting Typescript linting we still are missing many of the useful Angular specific rules in our linting so even the TypeScript linting is not 1:1.

Biome doesn't currently support HTML formatting and Angular control flow syntax, so we can't get formatted HTML without running Prettier anyway. And there are also useful HTML Angular ESLint rules we could leverage that are missing in Biome.

I have not used Biome extensively, but to me, in its current state this just doesn't seem like its ready to be a replacement. The current setup is confusing and complex, particularly for new developers and I'm not seeing the benefit of slightly faster linting/formatting justify the downsides?

[thatsamsonkid]

I agree with @ashley-hunter I think while speed is nice in this case it isn't really a pain point for us right now. Compatibility and familiarity, especially with new contributors is a pain point currently. I think we should move back to eslint/prettier combo and we can revisit it in the future if needed. I think the move to bun also already did quite a bit for us in terms of speed so I appreciate Ben for helping with that move.

[benpsnyder]

I don't mind putting eslint back in where it is useful ... no problem. I could help get this done before year end but November is quite busy for me at the moment

[thatsamsonkid]

No worries @benpsnyder and I think some us can definitely take care of it. I wasnt necessarily trying to get you yourself to do it. I think we just wanted to present our case for moving back because we know you worked on this and we didn't wish to undo all that work without a good reason