Lying to the Wizard
Every setup wizard is a decision tree, and every decision tree assumes it's planting a flag in untouched ground. Ask it whether your project uses TypeScript and it isn't really asking what's true, it's asking which branch of defaults to write. That works fine on an empty folder. It falls apart the moment a folder already has opinions in it from some other tool that ran first.
I hit this setting up a linter on a project that already had a framework-generated config sitting in the directory. The linter's own init wizard walks you through a few questions: what style guide, what module format, TypeScript or not. Answer honestly that yes, this is a TypeScript project, and the wizard quietly drops the one style guide you actually wanted off the list of choices. Not because the style guide doesn't support TypeScript, it does, with one extra parser package. The wizard's branch logic just doesn't know that, so it treats "TypeScript: yes" as disqualifying input and prunes the option before you ever see it.
The honest answer produces the wrong outcome. The only way to get the style guide you want is to tell the wizard no, this isn't a TypeScript project, let it write the config for the universe where that's true, then go back in by hand and bolt the TypeScript support on yourself. You're lying to a form in order to get the form to produce the result that was actually correct all along.
That's the part worth sitting with. It's not that the wizard is badly designed in some obvious way, it's narrow in a specific and almost reasonable way: it's optimized for the blank-slate case, where its questions really do map onto the decisions it needs to make. The failure only shows up once there's a second tool in the picture, one that already wrote its own partial config before the wizard ever ran. Now there are two sets of assumptions in the same directory that don't know about each other, and the wizard's decision tree, built for a world with exactly one set of assumptions, has nowhere to put the second one. It doesn't ask "what's already here." It can't; that question doesn't fit the tree.
So the lie isn't a trick, it's a workaround for a category the wizard never modeled. And it comes with a tax. Say no to TypeScript and the wizard also skips writing the TypeScript-specific rules, skips the parser config, sometimes skips or overwrites file extensions it would otherwise have included. You get the option you wanted and lose three things you didn't ask to lose, and now you're doing archaeology on your own config to figure out which of those three actually mattered. The repair isn't optional, it's the second half of the transaction you agreed to the moment you lied.
I don't think this is really an ESLint problem, or even a JavaScript tooling problem. Any setup flow that encodes its options as a sequence of yes/no questions is making the same bet: that the questions it's asking are the full set of facts relevant to the decision, and that nothing outside the conversation has already shaped the ground. Database migration wizards do this. Cloud resource templates do this. Anything that scaffolds into a directory that might already be a project rather than an empty one is exposed to the same failure, because the fix for it is reconciliation logic, not another branch. You'd have to detect the prior tool's output, understand what it implies, and merge rather than overwrite, and that's a much harder thing to build than a decision tree. So instead the wizard quietly assumes it's first, and when it isn't, the gap between what's true and what gets you the right answer becomes your problem to close by hand.
The uncomfortable part is that this makes lying the more sophisticated move. Telling the wizard the truth is the naive choice, the one that assumes the tool has modeled your situation. Telling it a convenient falsehood and repairing the damage afterward is the one that actually accounts for what the tool can and can't see. A good wizard should make the honest path the correct one. Until it does, knowing which questions to lie to is just part of knowing the tool.