Giters

typescript-eslint / tslint-to-eslint-config

Converts your TSLint configuration to the closest possible ESLint equivalent. 🚀

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

"error" rules should be "warn"

mgummelt opened this issue · comments

commented

🐛 Bug Report

  • tslint-to-eslint-config version: 2.9.1
  • ESLint version: 7.32.0
  • Node version: 14.17.5

Actual Behavior

tslint-to-eslint-config is generating a .eslintrc.js file mostly filled with "error" rules.

Expected Behavior

tslint-to-eslint-config should generate an .eslintrc.js file mostly filled with "warn" rules. This was the previous behavior of tslint. For instance, an unused variable (no-unused-vars) should be appearing with a yellow squiggly in VS Code, not a red squiggly.

Reproduction

I can include my tslint.json if needed, but I imagine this behavior is not dependent on any specific config. I also imagine I'm missing something obvious, since everyone must be experiencing this same behavior.

commented

Hi @mgummelt, thanks for raising! tslint-to-eslint-config generally tries to keep the same error severity as before: if a rule was set to TSLint's "error" it will be output as ESLint's "error". The severities are equivalent. I suspect this is more of an difference in settings with the tooling you're using to run ESLint or TSLint. Can you post your rule configs and any settings you were using for your editor extensions, such as .vscode/settings.json?

Rambling: this brings up a great question about tooling and the nature of an "error" in an inherently "warning"-based tool like a linter. Lint complaints by nature are not complaints that need to block code compiling, so what's an "error"? Should tools by default surface lint complaints as "warnings" (e.g. yellow squigglies instead of red)? But then how do we differentiate between levels of warnings within the tool itself? Should an ESLint's "error" be considered an error within ESLint but a "warning" in wrapping toolings? Personally, I think so, and generally use the vscode-eslint "severity": "downgrade" option to make editors surface them that way.

commented

@mgummelt I'm feeling somewhat confident that leaving errors as errors is the right way to go. Closing this issue to keep the list of open ones small: but do post back here if you think I should re-open!