Linting for ES6 + JSCS rules about react-project-legacy- HOT 5 OPEN

ESLint offers linting for ES5 - ES7 and code style enforcement. This may be the better option over jshint and jscs.

from react-project-legacy-.

I need this rule to be added in so that I can define styles below my React class definition.
"no-use-before-define" : 0

from react-project-legacy-.

A few suggestions:

1. no-console & no-alert should be disabled. Some designs call for alert and confirm boxes, and console.logs are necessary for errors.
2. prefer-template "Unexpected string concatenation" should be disabled. This throws an error when string concatenation happens in an object value, which is sometimes called for and would be superfluous to concat in a variable before hand.
   eg:

const style = { width : 118 + 'px', height : 118 + 'px', lineHeight : 120 + 'px', };

1. no-underscore-dangle should be removed. Throws an error when identifiers begin with underscores. I do not name variables or functions myself beginning with an underscore, but it is popular to do so in a lot of npm packages.
   eg:
   this.props._onClick()
2. vars-on-top should be removed. Throws an error when vars are not defined at the top of a function. Sometimes the code is easier to read when vars are declared directly above where you need them. For example, if you have a long function with an if statement and a for loop, it would be nice to define a variable used only in the for loop right before it rather than declaring it way out of sight.

from react-project-legacy-.

The idea behind no-console and no-alert is that you don't use these outside of development, or rather, prevent them from being committed so deployments to production environments aren't littered with these methods. I agree that no-alert should be disabled, but I think no-console could be good for habit building as console logs in production is a pet-peeve of mine.

I agree with prefer-template and no-underscore-dangle as well. I use preceding underscores frequently to denote "private" or "hidden" variables. However, vars-on-top is often considered a good practice and I would like to see that utilized.

from react-project-legacy-.

I would like to also add this rule because there are many instances while using a switch statement that do not need a default. "default-case" : 0

from react-project-legacy-.