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

feat: Drop custom eslint for Prettier #84

Closed
3 tasks done
joshwiens opened this issue Oct 1, 2017 · 4 comments
Closed
3 tasks done

feat: Drop custom eslint for Prettier #84

joshwiens opened this issue Oct 1, 2017 · 4 comments

Comments

@joshwiens
Copy link
Member

joshwiens commented Oct 1, 2017

This has been discussed via slack on more than one occasion. Prettier has the benefit of both excellent tooling integration as well as end an future debates about code style.

  • Update defaults to run gel with Prettier including the addition of prettier-eslint
  • Deprecate eslint-config-webpack
  • Include configs for all supported editors ( Sublime, Code, Atom, Vim? )

We may as well get this over with if only to limit the amount of rework for the remaining defaults conversions / incoming transfers.

Everything in the 2.0 milestone should target https://github.com/webpack-contrib/webpack-defaults/tree/next

//cc @webpack-contrib/org-maintainers

@sapegin
Copy link
Member

sapegin commented Oct 1, 2017

It’s not clear whether you want to remove ESLint entirely or just disable style rules.

@joshwiens
Copy link
Member Author

I intend to deprecate eslint-config-webpack and replace it with Prettier & the eslint config that complements Prettier so they aren't stepping on each other.

Based on the feedback during conversions, the existing config is a bit restrictive in certain areas. So the end result is Prettier + prettier-eslint with the latter replacing the existing eslint-config-webpack as it pertains to this tool.

@michael-ciniawsky
Copy link
Member

I personally think we still need eslint-config-webpack for Code Quality Rules, but as @sapegin suggested, removed with all style related rules :)

@joshwiens
Copy link
Member Author

Should have been more clear, we will base our style rules off of the config that works with prettier & then extend as we see fit taking into consideration some of the pain points people have highlighted during the first set of conversions to defaults.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants