Annoying messages from eslint

[BobNobrain]

Sometimes eslint just spams me with irrelevant parsing error messages (because it is enabled "on type"). For example, in the following code:

import React from 'react';

export default function Test() {
    React.useEffect(/* cursor goes here */)
}

i keep getting error messages with this stacktrace:

[Error - 4:15:39 PM] TypeError: Cannot read property 'type' of undefined
Occurred while linting <project>/.../test.tsx:4
    at visitCallExpression (<project>/node_modules/eslint-plugin-react-hooks/cjs/eslint-plugin-react-hooks.development.js:1734:24)
    at <project>/node_modules/eslint/lib/linter/safe-emitter.js:45:58
    at Array.forEach (<anonymous>)
    at Object.emit (<project>/node_modules/eslint/lib/linter/safe-emitter.js:45:38)
    at NodeEventGenerator.applySelector (<project>/node_modules/eslint/lib/linter/node-event-generator.js:256:26)
    at NodeEventGenerator.applySelectors (<project>/node_modules/eslint/lib/linter/node-event-generator.js:285:22)
    at NodeEventGenerator.enterNode (<project>/node_modules/eslint/lib/linter/node-event-generator.js:299:14)
    at CodePathAnalyzer.enterNode (/<project>/node_modules/eslint/lib/linter/code-path-analysis/code-path-analyzer.js:711:23)
    at <project>/node_modules/eslint/lib/linter/linter.js:954:32

    at Array.forEach (<anonymous>)

Is there a way to somehow mute this messages?

[dbaeumer]

Currently no. All I can think of having a setting for this that avoid the notification.

[BobNobrain]

I think this would be a reasonable solution. When the setting is enabled, it just converts all these errors into some warning messages that appear in extension's output channel, but do not open this error popup. (I also wonder if there is some way to aggregate these popups into a single one, but that probably cannot be done from within the extension).

[egucciar]

+1 for this, its a constant headache since i updated VSCode

[mkvlrn]

Yes, PLEASE. I've tried finding a way to completely disable VSCode notifications (there isn't a way) because of that.

React's useEffect and changing some import paths in a node/typescript app wil absolutely SPAM (like a LOT LOT, I'm talking 30 messages) in a short period of time and you need to close ONE BY ONE.

I have seen that before once in a while (usually only with useEffect) but it's gotten much much worse. It used to be distracting but now it's flat out aggravating.

[jalajcodes]

Everytime I type useEffect() this notification pops up, but just 1 popup not 30+ like other folks said above.

[patrickdean]

+1 for this as well. If this is enabled on type perhaps there could be a setting that enables it on save instead? Or maybe even report these could be reported in the 'problems' tab rather than the output?

[rhyek]

This has been driving me crazy for months. This always happens when using either useEffect or useLayoutEffect.

[justingrant]

(merging in content from my dupe #1322)

When ESLint encounters an exception, it will show a popup warning box in the IDE which must be manually dismissed by the user. For example, when I typed const on a new line in a JS file, I got an error dialog.

Obviously ESLint itself or its plugins (e.g. typescript-eslint) has a bug here and shouldn't be crashing. But IMHO it's not good to subject VSCode IDE users to dialogs caused by bugs in linters that most users can't fix, especially when most of these problems fix themselves once the user edits their code to fix the problem that caused ESLint to crash.

The same is true for "can't load config" errors as described in #1182 (comment). The VSCode user can't do anything to fix someone else's code, so putting up an error box isn't helpful.

IMHO, a better UX would be to report errors without requiring the user to dismiss them. Then, even if ESLint is temporarily broken (or broken for just one file), the developer could still keep working without interruption.

The VSCode Prettier extension handles this nicely. Instead of a modal, it shows status using an icon in the status bar, e.g.
- ignored file
- OK
- file can't be parsed

If the user wants to see details behind problems, they can click the status bar to get taken to the output pane to see details.

Could vscode-eslint do something similar?

[tizmagik]

+1 to @justingrant 's suggestion of mimicking how Prettier handles this. I'd be happy to contribute a fix if someone could point me in the right direction...

[dbaeumer]

@tizmagik VS Code is currently working on a language status API which we should use instead. It is in a proposed state here: https://github.com/microsoft/vscode/blob/main/src/vs/vscode.proposed.d.ts#L2933

IMO we should use this since it will help to declutter the status bar. If you want to give it a try I can help you with that.

[justingrant]

Here's the issue discussing the new language status API: microsoft/vscode#129037

@dbaeumer the code link in the comment above is no longer valid. It points to a line that doesn't exist anymore.

[dbaeumer]

New link: https://github.com/microsoft/vscode/blob/main/src/vs/vscode.proposed.d.ts#L2841

[dbaeumer]

I did the coding but the new language status API is still proposed. Has to wait a little.

[justingrant]

I did the coding but the new language status API is still proposed. Has to wait a little.

Is the new language status API available?

[dbaeumer]

Yes, but I have not merged the branch Yet.

[Meligy]

Yes, but I have not merged the branch Yet.

Is there any other issue blocking this to follow it?

[dbaeumer]

No, just time :-)

[dbaeumer]

If someone wants to continue this, the branch is: origin/dbaeumer/languageStatus

[charlestbell]

+1 for getting these eslint warnings to go away. They just stack up in the viewport all day long.

[charlestbell]

+1 for getting these eslint warnings to go away. They just stack up in the viewport all day long.

[waynebloss]

Is there any fork or alternative to this extension? I don't care when ESLint can't load a config or whatever - I'd just rather see a red thing in the status bar or whatever, instead of a notification whenever I open a file in a space that isn't configured properly yet...