Vscode-eslint: Minimise activationEvent scope

[jasonwilliams]

Instead of the * currently in use (in package.json), it would be better to use onStartupFinished.
I believe this would need to bump the minimum version from 1.43 to 1.46 but sounds like it would be a worthwhile change for user experience and performance.

I’ve also noticed this plugin running in process explorer when working in other projects, like Rust for example.
Should it have an onLanguage[javascript, typecript]: guard also/instead?

[dbaeumer]

onStartupFinished will only delay the startup. The plugin is written in a way that the activation itself is pretty fast. It doesn't start the eslint server either. Only when a file type opens that is considered to be validated.

The problem with ESLint is that it has plugins and can therefore validate file types different than TS/JS. Since the list is pratically open ended onLanguage doesn't work.

Any objections to close the issue?

[jasonwilliams]

@dbaeumer hmm even if startup is fast I’m not sure why it needs to be started instantly over after VSCode has started? The docs themselves say to use * “only when no other activation events combination works”.

I agree about language, it sounds like that’s not really possible to guard like you said.

[robole]

I agree with Jason that this is unusual @dbaeumer .

Having an extension active all the time should be avoided unless its use is almost universal. ES Lint typically targets JS and TS. I understand that ESLint can target other languages through plugins, but would it not be more sensible to target the default languages by default?

Emmet's setup in VS Code could be a good pattern to follow. Emmet has 2 setttings includeLanguages and excludeLanguages to control the languages it targets. It has a default list of: html, haml, pug, slim, jsx, xml, xsl, css, scss, sass, less and stylus files. Also, any language that inherits from one of the above languages is supported e.g. handlebars.

A much simpler mitigation is to use the workspaceContains activationEvent. You provide appropriate glob patterns, so it is only activated for projects which contain certain file types.

"activationEvents": [
    "workspaceContains:**/*.js"
]

[dbaeumer]

I do agree but with ESLint this is a chicken and egg problem since you can add a plugin that adds validation for arbitrary file types. So whether you activate on file patterns or language ids will not make a difference. This is why the ESLint extension activates with a minimal main and then inspects a setting which you can only react on if the extension is running.

The only difference that onStartupFinished makes is the activation timing not whether the extension gets activated.

[robole]

It's your decision @dbaeumer . I know it's an awkward situation!

The way I use the extension now is to have it disabled by default, and only enable it for JS and TS projects. I don't want it loading on startup for backend projects.

I think changing the Activation Event to onStartupFinished to prevent it loading on startup would be welcome. That doesn't impact how you can use ESLint, it just adds a small delay to activation.

[dbaeumer]

The extension now activates onStartupFinished

https://github.com/microsoft/vscode-eslint/blob/master/package.json#L27