3 ms·

The problem is that tools like ESlint often come with highly opinionated rules that might not even be applicable all of the time (leading to me having to manual

The problem is that tools like ESlint often come with highly opinionated rules that might not even be applicable all of the time (leading to me having to manually turn them off via annotations) And there's no centralized idea on best practices.

__alexs 1y ago
eslint is slow and has terrible UX. Use Biome instead.
- torginus 1y ago
  Hi, I'm you from the future. Biome is slow and has terrible UX. Use Tokamak instead (/s)
  - __alexs 1y ago
    Biome has several advantages that make this future unlikely and evidence from similar attempts in other languages seems to support their direction. Such pessimism is unwarranted.
HelloNurse 1y ago
And best practices depend. Recently, I discovered that the ruff linter for Python doesn't like the assert statement, because since it does nothing in "optimized" mode it isn't reliable. But such complaints about unit tests are not particularly useful.
- mr_mitm 1y ago
  Rule S101 [1] is not in the default settings. If you choose to enable it, you have the possibility of disabling it for your tests like so: [tool.ruff.lint.per-file-ignores] "tests/*" = ["S101"] (Besides, this was about formatting, not linting, but I realize it's related.) [1] https://docs.astral.sh/ruff/rules/ https://docs.astral.sh/ruff/rules/
Cthulhu_ 1y ago
ESLint is the centralized idea I suppose, but getting consensus is difficult. When it comes to formatting, there's other languages (Go, Python?) that have clear, top-down guidelines applied by tooling, at least for code style. I think that's clever, and besides the odd mailing list post trying to change it because of a personal preference, it minimizes discussions about trivialities over the really important things. Because 2 vs 4 spaces or line length discussions are ultimately futile; those aren't features, individual preferences don't matter. Codebases have millions of lines and thousands of developers; individual opinions do not matter at scale, consistency does.

__alexs 1y ago

eslint is slow and has terrible UX. Use Biome instead.

torginus 1y ago
Hi, I'm you from the future. Biome is slow and has terrible UX. Use Tokamak instead (/s)
- __alexs 1y ago
  Biome has several advantages that make this future unlikely and evidence from similar attempts in other languages seems to support their direction. Such pessimism is unwarranted.

HelloNurse 1y ago

And best practices depend. Recently, I discovered that the ruff linter for Python doesn't like the assert statement, because since it does nothing in "optimized" mode it isn't reliable. But such complaints about unit tests are not particularly useful.

mr_mitm 1y ago
Rule S101 [1] is not in the default settings. If you choose to enable it, you have the possibility of disabling it for your tests like so: [tool.ruff.lint.per-file-ignores] "tests/*" = ["S101"] (Besides, this was about formatting, not linting, but I realize it's related.) [1] https://docs.astral.sh/ruff/rules/ https://docs.astral.sh/ruff/rules/

Cthulhu_ 1y ago

ESLint is the centralized idea I suppose, but getting consensus is difficult. When it comes to formatting, there's other languages (Go, Python?) that have clear, top-down guidelines applied by tooling, at least for code style. I think that's clever, and besides the odd mailing list post trying to change it because of a personal preference, it minimizes discussions about trivialities over the really important things. Because 2 vs 4 spaces or line length discussions are ultimately futile; those aren't features, individual preferences don't matter. Codebases have millions of lines and thousands of developers; individual opinions do not matter at scale, consistency does.