Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove ESLint user-related config #687

Open
wants to merge 4 commits into
base: master
from

Conversation

@Kocal
Copy link
Contributor

Kocal commented Jan 12, 2020

Hi

This PR is a proposal for #657 implementation and should fix issues encountered in #473, #574, #656, #659, and #685.

As discussed in #657, it would be better if Encore didn't configure ESLint itself. It should be done by the end user in an configuration file (e.g.: .eslintrc.js)

ESLint's parser option is not configured by default anymore, and babel-eslint requirement has been removed. We can considering this as a breaking change, end users should now configure parser: 'babel-eslint themselves.

Method Encore.enableEslintLoader('extends-name) has been deprecated and undocumented, in order to prevent end users to configure ESLint through Encore.

A nice message is also displayed when no ESLint configuration is found:
Capture d’écran de 2020-01-12 11-15-09
I couldn't use FriendlyErrorsPlugin for this because error is not coming from Webpack. If someone has a better idea... 😕

Pros:

  • end users have now full control hover ESLint configuration by default
  • no need to delete options.parser when trying to use eslint-plugin-vue or @typescript-eslint/parser
  • IDEs will be able to integrate ESLint (if they support it)

Cons:

  • end users should now configure parser option to babel-eslint themselves
  • end users will have to move their config to external config file, but it's ok

What do you think?
Thanks.

EDIT: tests failures are unrelated I think.

@Lyrkan
Lyrkan approved these changes Jan 13, 2020
@Lyrkan

This comment has been minimized.

Copy link
Collaborator

Lyrkan commented Jan 13, 2020

Thanks @Kocal, I think that we really need this :)

I couldn't use FriendlyErrorsPlugin for this because error is not coming from Webpack. If someone has a better idea... 😕

Not a big issue imo, the message looks fine (edit: ahah, no wonder it looks fine and really similar to the ones we already have after pushing that missing commit 😄).

EDIT: tests failures are unrelated I think.

Yeah, the ones on AppVeyor have been there for a while now (and I still have no clue what causes them...), and the ones on Travis are related to TypeScript (a bit weird that they only happen for that job though).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.