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

Investigate style enforcement tools #734

Closed
gaearon opened this issue Sep 24, 2016 · 9 comments
Closed

Investigate style enforcement tools #734

gaearon opened this issue Sep 24, 2016 · 9 comments
Milestone

Comments

@gaearon
Copy link
Contributor

gaearon commented Sep 24, 2016

I don't think style enforcement should be part of our linting process. It's too annoying to see formatting messages in console and browser warnings as you write code.

Nevertheless I think it's a good idea to enforce style automatically. For example, before pushing your changes.

We don't want to enforce any particular style in CRA projects but I want to either document or integrate with popular automatic code formatting tools.

I don't plan to look into this personally but I'd love somebody to help us out and investigate what's out there in the ecosystem, and how we could use that in CRA.

Constraints:

  • Should offer different styles (at least semi / no-semi)
  • Fixing violations should be automatic and as easy as npm run format which could be like react-scripts format semi
  • The tool should understand all of the syntax we use (ES6, JSX, class properties, async await)

Desired outcomes:

  • We know which style enforcement tools exist and how they differ from each other
  • If there is one fitting our workflow, we have documentation on integrating it into CRA project
  • If it's really good we might even include it into CRA

If you'd like to help, please write in this issue! I think it's fine if several people look into this at the same time so this task is open to everyone.

@gaearon gaearon added this to the 1.0.0 milestone Sep 24, 2016
@robertknight
Copy link

I've used a combination of typescript-formatter for basic formatting of JavaScript source files followed by eslint --fix to deal with easily fixable style violations such as missing/extra semi-colons, missing/extra commas at the end of lines in object/array literals etc. typescript-formatter supports ES6 and JSX, but AFAIK it doesn't yet support rest/spread object properties or the full range of Flow syntax (since there are some differences between TS and Flow syntax).

I think ESLint is a good fit for basic style fixups since you're already using it. For the initial code formatting part you probably want something based on the Babel toolchain however.

@danharper
Copy link
Contributor

danharper commented Sep 24, 2016

Sounds like ESLint's --fix does everything you'd need. For extended syntax which ESLint doesn't support natively, there's usually additional plugins which provide linting rules & autofixing, e.g. eslint-plugin-babel, eslint-plugin-flowtype.

@bojand
Copy link

bojand commented Sep 24, 2016

https://github.com/sindresorhus/xo some config might work.

@mxstbr
Copy link
Contributor

mxstbr commented Sep 24, 2016

@okonet might be interested in this. His lint-staged project can be implemented to have the exact behavior you want, for example with ESlint!

@okonet
Copy link

okonet commented Sep 24, 2016

Thanks @mxstbr for bringing this up. I'm definitely interested in this. I'm using lint-staged for all my projects and I can't recommend it enough especially along with eslint --fix combination. What steps are required from my side to make it happen?

@suchipi
Copy link

suchipi commented Sep 24, 2016

Since there are already tons of eslint rules and plugins that do enforce style, it seems like leveraging eslint --fix (with an eslint config that is different from the builtin one) would be a good approach

@gaearon
Copy link
Contributor Author

gaearon commented Jan 10, 2017

This is more or less what I wanted (from @jlongster).
I’d like to investigate integrating it by default.

http://jlongster.com/A-Prettier-Formatter

@Graham42
Copy link

Graham42 commented Jul 31, 2017

Can we consider this issue a duplicate of #451 ?

@gaearon
Copy link
Contributor Author

gaearon commented Jul 31, 2017

Yep.

@gaearon gaearon closed this as completed Jul 31, 2017
@lock lock bot locked and limited conversation to collaborators Jan 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants