Hmm, I'm [edit: not] a huge fan of adding globals in implicitly. DOM being on-by-default is more of a convenience for the common case of writing browser apps. I don't think that's something we'd want to put as a default for lint rules. (I don't even think it should be on by default anymore for TypeScript itself, were it not for legacy support)

I think a cleaner direction would be to manually change docs-eslint-output-snapshots to match what's on the playground. Thoughts @typescript-eslint/triage-team?

Hmm, I'm a huge fan of adding globals in implicitly

Guessing you missed a not 😉

Anyways, I'm fine either way, but a couple points to consider —

• I don't think of this as "adding globals in implicitly" but "matching the default settings of TS". TS may do by default what it does, but we want our unit tests to match how our users use typescript-eslint, and I would venture to guess that a vast majority of code is running with lib: DOM because it's part of TS's default. (Of course, whether that is correct or not is a separate story.)
• Additionally, whatever we choose, I think it's important that these three things stay consistent - (A) the lib used for our individual rule unit tests, (B) the lib used for docs-eslint-output-snapshots, and (C) the lib used (by default, of course) in the playground.
  • Right now, (A) and (B) are consistent while (C) is different. My linked PR aims to make all three consistent.
  • If I'm understanding your suggestion correctly, @JoshuaKGoldberg , you're proposing changing (B) to match (C) while making it inconsistent with (A), which I'm not sure is much better than where we're at now.

On the other hand, if we do not add lib: DOM because

I don't think that's something we'd want to put as a default for lint rules

• — in other words, the philosophy is "our lint rules should be agnostic to a browser or non-browser environment", then I would argue we should consider why our docs mention things that are only available in lib: DOM, such as
  • The examples in the snapshot of the linked PR
  • as well as places like no-base-to-string => URL and URLSearchParams, because those types are not part of the default lib — they are only available in lib: DOM or @types/node.

matching the default settings of TS

Heh, "why not both?" - the default settings of TS are to implicitly add in globals! (not disputing thinking of it as one or the other, just amused)

we want our unit tests to match how our users use typescript-eslint

I'd say that's a good general rule, but so is being overly precautious. Sometimes we in typescript-eslint accidentally use DOM/etc. globals we shouldn't, as you've noted.

we should consider why our docs mention things that are only available in lib: DOM

Because we're sloppy 😄. We context switch a lot and take in contributions from people who have even less context than us. Those are bound to get messed up a whole bunch. To me, that discrepancy is a symptom of the issue!

Following up: let's switch the playground to default to not having "dom" in the lib.