Closed jaydson closed 9 years ago
UltCombo
commented
9 years ago I personally don't care much either way -- although I believe keeping a consistent coding style is important, I can also see that a lot of time is wasted struggling with those tools at the moment.
I believe we can just monitor ourselves (while writing code & reviewing PRs) in order to keep the current coding style.
UltCombo
commented
9 years ago Many JSHint/JSCS issues regarding ECMAScript 2015 have been fixed -- https://github.com/es6rocks/harmonic/commit/d6408f528d5a789de7a135ca09e4d987be9b969b.
But it got me thinking, if we are going to be using the latest bleeding edge ECMAScript.next features in the future, and these features keep landing first on transpilers than on linters, this would get us into an infinite loop where our code can never be linted due to linters being behind transpilers regarding ECMAScript.next support.
Just food for thought. cc @jaydson @leobalter
jaydson
commented
9 years ago That's true @UltCombo, and hard to solve. I was thinking about http://eslint.org/. I know we can customize the rules, but i didn't dig the docs yet and i don't know how is the support for ES6, ES7, etc. Perhaps, we can evaluate it.
UltCombo
commented
9 years ago Yeah, in my opinion we can keep this as low priority for the time being.
Harmonic's main goal is to be an Static Site Generator built with ES6(ES7?), exploring new features, finding bugs in the spec and help to evolve the language. Harmonic's current configuration and work-flow doesn't match with the target, because both JSHint and JSCS have issues with the new and future spec. I think we need to disable those tools by now and focus on what really matter. In the near future when JSHint and JSCS have full support for features we're using, then we can re-enable them. Thoughts?
//cc @UltCombo @leobalter @felipenmoura