C:\Code\kaliber5\wbc\config\dotenv.js
5:18 error Missing return type on function @typescript-eslint/explicit-function-return-type
Versions
package
version
as per the rule's readme, and the 2.0 release notes - this is working as intended.
If you have a mixed js/ts codebase, you should use eslint overrides to disable the rule for js files.
Related: #906
I had tried overriding it the other way (allow by default, disable for .js) and failed.
I have now applied the recommended way (disable by default, enable for .ts). It works!
rules: {
// disable the rule for all files
"@typescript-eslint/explicit-function-return-type": "off"
overrides: [
// enable the rule specifically for TypeScript files
"files": ["*.ts", "*.tsx"],
"rules": {
"@typescript-eslint/explicit-function-return-type": ["error"]
As per the documentation, the rule in question should only be enabled on TS files. However, it is enabled on every file by default in plugin:@typescript-eslint/recommended.
Ain't this a bug that should be fixed?
Please consider reopening.
No, it is not.
This is an intentional decision.
ESLint has overrides so you can choose which files to run what rules on.
If you configure it on a js file, it'll report errors you can't fix.
The way to fix it is mentioned above.
Well, why does it intentionally apply rules to files that don't work together?
We know the rule crashes on JS files and is intended for TS files only. Why don't we apply it to TS files only?
I feel like this is The Inmates Are Running the Asylum type of situation: it was easier for maintainers to set up the plugin that way, and that's it. They cared for the convenience of their development more than the usage experience for plugin consumers.
As an end user, I can't think of a single reason why that rule should not be applied to TS files only. :/
Because we don't know your exact setup.
Restricting file extensions isn't something you do in eslint plugins because you never know what the end-user's setup is.
In particular, if we only run it on ts files (like we did before the 2.0 release), then users using markdown, or vue, or mdx, or any other file extension wouldn't be able to use the rule.
You'll find the same problems if you use eslint-plugin-jest. If you have functions called expect, it, or describe outside of a test file, you'll get weird errors. Which is why it's recommended to use overrides to specify the paths of your test files.
Or if you have a backend/frontend monorepo and you have eslint-plugin-node installed, and you don't use overrides to restrict the plugin to your server files, then you might get weird errors in your front end.
Etc, etc.
The standard for eslint is: "we don't know your environment, so configure it yourself to suit".
We clearly document it in the readme so you know about this case..
Well, my point is that your default setup is faulty and affects a huge portion of users, and the reasoning behind it that you want to protect exotic setups used by a tiny portion of users.
Why? Those elaborate setups require a deeper knowledge of eslint and typescript-eslint anyway. If you set up TS in Markdown, Vue and MDX, you won't have a problem setting up exceptions.
But every novice user who has a JS file in their codebase will stumble upon this. Every user will get frustrated, will need to google it up and adjust the config to fix the faulty defaults. 😕
