search

bencodezen / vue-enterprise-boilerplate

An ever-evolving, very opinionated architecture and dev environment for new Vue SPA projects using Vue CLI.
7.78k stars 1.32k forks source link

eslint not working? #133

Closed plehnen closed 5 years ago

plehnen commented 5 years ago

Hi, there is one thing which I don't understand:

In your vuex state modules (e.g. auth.js) you have an export const state and further down you use the same variable name state as a parameter.

In my old project I get an error indicated, that:

ESLint: 'state' is already declared in the upper scope. (no-shadow)

Both projects, the old and the new, uses eslint, with very similar looking dependencies. Just different versions. Searching for "no-shadow" brings no result in both projects. So why is this rule not applied in your setup? Is it depricated? Disabled? Am I missing something?

chrisvfritz commented 5 years ago

It sounds like you're extending from a config that enforces no-shadow, like the AirBnb config for example. You can override it by adding "no-shadow": "off" to your ESLint config, or use ESLint overrides to turn it off only for the folder where your Vuex modules live if you'd like.

plehnen commented 5 years ago

Hey, thanks for your feedback. Actually it is the other way around. I was wondering why such eslint rules do not warn me in your project! The "no-shadow" was just one example. There are several eslint-rules which doesn't show up in your boilerplate, and I don't understand why.

For this particular example: I see why the no-shadow rule makes sense. Shouldn't this be fixed in your auth.js? So that the inner "state" variable is named differently than the outer variable. And shouldn't eslint warn about this "error"?

chrisvfritz commented 5 years ago

ESLint doesn't enable any rules by default - it only provides the tools to enforce your desired style. Even the official eslint:recommended config leaves many rules disabled, including no-shadow. This particular rule is useful to some people, which is why it exists, but it also prevents use of a valid and useful pattern that is unlikely to cause misunderstandings with modern tooling, like the go-to-definition and definition highlighting that's available in many modern editors.

Does that make sense?

plehnen commented 5 years ago

Absolutely. I wasn't aware that there is a difference between "recommended" and those ... 'general' rules. I didn't know that I have to explicitly "opt-in" those rules. So I thought eslint would not work at all. Thanks for making this clear :)