We should not have per-folder TS Config and lint rules

[bpasero]

Referring to:

vscode/eslint.config.js

Line 1438 in d790d95

// Prompt files related code

and

src/vs/platform/prompts/tsconfig.strict.json

[legomushroom]

Thought it is OK to at least temporary have there since we do already have these per-folder configs already, for instance

vscode/eslint.config.js

Line 1359 in d790d95

// Terminal

and

vscode/eslint.config.js

Line 1416 in d790d95

// typescript-language-features

Another reason I thought this would work is the fact that we already have the code stratified by the owner and hence somewhat already have the rules, just not explicit ones in the form of the linting. Today the code owner yells on folks, I instead tried to automate that. I believe the automation reduces inter-developer tensions, and also saves a lot of time because the folks get an immediate feedback and guidance from the linter.

I see that there are a lot of code style opinions around, therefore I didn't add any stylistic rules on-purpose - only the strict rules to ensure code correctness(which already found great issues!) My plan always was to bring it up in the dev discuss channel and try to convince folks to adopt some of the stricter rules (I still plan to of course). Given the usual duration of a project-wide adoption effort and how much time it usually takes to navigate through the linter rule discussion wars, I figured that getting a good set of rules enforced would probably take years. So it made sense to me to get the ball rolling at least for the code that I have some control of, while trying to get broader rules available. Again, I see a huge value in making robots to yell on people instead of me.

We've talked about this with @bpasero a bit in Slack today, and we decided to bring up this to the dev-discuss. For me plan is to find the most-impactful correctness rules with the lowest possible churn to the codebase, then assess a rough cost for project-wide adoption, and finally to start convincing the folk to adopt. Even a single adopted rule can yield a large increase in product robustness and save a lot of time during the end game, so I totally believe this is something worth striving for. On the other hand, I see the correctness rules as the most valuable generally and I probably can live with any "style"/"names" ones if they are well-defined and consistent across the codebase.

[bpasero]

👍 on your last point, lets try to avoid per-component rules and put them globally. This includes TSConfig rules as well as ESLint rules that we either pick or implement if not existing yet. We have had a lot of adoptions in the past that we were able to adopt incrementally. @mjbvz for example worked on many in the past, when TS added new features.

[roblourens]

I don't really see an issue with per-component rules personally. As long as it isn't going in a totally different direction and we try to push things up to the global level when possible.