What is the difference between installing eslint as extension and installing as npm package?

Question

I have been following various blogs and videos on setting up and configuring eslint and prettier for vscode and development. But every article fails to explain why do we need to separately install eslint as an npm package and vs code extension?

what difference it will make if I install either of the ones?

Answer 1

why do we need to separately install eslint as npm package and vscode extension?

Short answer: you don't.

Long answer:

Installing ESLint/Prettier as extension, allows you to format/check your code inside the VSCode.

However, installing them also as dependencies brings extra benefits:

• VSCode will use exact same package as installed. So you will not spot the situation when VSCode says OK, but your CI server says: NOT OK
• You will get control over the versions, and can update whenever you want
• You will be able to use different versions for different projects. This is especially important, when you can't migrate old project, but want to use the latest possibilities for the new one
• You will be able to access Prettier/ESlint through the script block of the package.json, and be able to write custom commands with parameters exactly as you need
• You will be able to pair them with Husky or NPM hooks to automatically verify/format the code

From my experience, if you can install something locally - install it as package dependency (except CLI like create-react-app or angular-cli that helps you start the app). This will make your life a bit predictable.

Answer 2

These programs can format your code (ESLint and Prettier) and detect specific syntax (ESLint).

When installed as an extension in your IDE (vscode for example), you can get:

• squiggly lines in real time;
• and format-on-save.

But someone who starts up your project on their own environment might not have these extensions installed (might not even have the same IDE) and thus might not get these.

When installed as npm packages (and included somewhere in the pipeline, either in the npm start, or in your continuous deployment, or...)

• you won't get real time squiggly lines,
• but you can still get auto-formatting (though not necessarily on save, depending on the configuration),
• you can get blocking rules (meaning instead of just seeing errors / warnings, you can actually block the pipelines until the dev fixes said errors / warnings)
• you can insure anyone who starts the project, from any IDE, gets the packages included