We do set it in the base config which all configs extend

https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/src/configs/base.ts

I personally always liked the user setting it explicitly because it means that it hard-overrides what any config might do - which prevents weird issues like the user doing extends: ["plugin:@typescript-eslint/recommended", "some-config-that-sets-another-parser"].

For example sometimes people extend the angular or Vue configs which can set other parsers as default and cause weirdness. Imagine if they extended a config that set the babel parser!!!

I think the one line in the example is worth warding against the potential bullshittery

How often do folks set parsers other than ours for TypeScript code? I've never seen it in the wild, and only heard mention of it from #6814.

I think the one line in the example is worth warding against the potential bullshittery

Would you still consider the warding worth it post #8146? Personally, I wouldn't.

Oh, and #8150: if we can roughly guarantee folks aren't pulling the potential bullshittery, I suspect the downsides would be much lessened.

Would you still consider the warding worth it post #8146?

Yes because the problem is not type-aware rules. That's certainly one problem but the issue is that if someone uses eg babel's parser then they'll get "undefined behaviour" which is MUCH worse than an explicit error from our rules because you don't know its happening - you'll maybe get false positives as the AST is broken, or you might get crashes, or even worse you could get false negatives and not know anything is wrong!!!

How often do folks set parsers other than ours for TypeScript code?

Now-a-days not on purpose for the most part - but some people still try swapping it out for misguided reasons.

But most often I've seen it happen due to people doing things accidentally. I'm on mobile so search sucks - but recently there was an issue where someone was in the exact I mentioned - they'd extended a config which had set the babel parser as it was a JS config.

Considering the getting started guide is 4 lines I think it's fine for us to include it. It also serves as a nice point of education about how ESLint works - "we are providing configs, plugins and a parser for you"