Finalize and cleanup our eslint/jscsrc setup.
This can be a working standard that evolves over time -- but we should get something in place now so that we can start collecting feedback.
(Dave has a few tweaked config files attached - they need more work though)
Then apply these styles to [#7919].
Diff:
Related
Tickets:
#7919[#7919] adds
.jscsrc
and.jshintrc
but those can be changed or removed as needed.Related
Tickets:
#7919Diff:
Diff:
Related
Tickets:
#7919I think the Google style guide settings are pretty good, at least I like in terms of variable capitalization, where to put spaces, etc. A few things I'd probably tweak if it were all up to me:
I agree with these. Anyone else want to weigh in on the eslint rules?
For reference:
Full list of options for eslint
Google style guide for javascript
Ready for review at hs/8035
For QA:
1. run npm install.
2. run npm run lint
most fixes are one per commit.
Can we have a separate .eslintrc for ES5 files? The
.eslintrc
file from master needs to be kept around in some fashion and used indef validate_js
so thatallura.tests.functional.test_static:TestStatic.test_static_controller
and inline_js tests work correctly.For the
no-unused-var
changes, I prefer to allow unused function params likee
for event handlers,i
for some loops, etc, as an indicator of what the function signature actually is even if they aren't used. This can be permitted with"no-unused-vars": [2, {"vars": "all", "args": "none"}],
. What do you think?In the browser, I get an error "ReferenceError: module is not defined".
Grouping threshold input box shows up at the wrong time, I think the
!!
->Boolean
change messed it up. Also its tooltip has backslashes in it.Also, for variable declarations, I'm not used to the "one-var" setting of each var on its own line, but I can get accustomed to it. However, that also permits vars to be declared further down in a scope (e.g. within a loop or within an if statement) which can cause accidental logic bugs since they are actually scoped to the whole function. How about we enforce
vars-on-top
?I agree. I added the "vars-on-top" -- it also encourages the use of "let" over "var" for block scoped variables. Good call.
I could go either way on the “one var per line” rule. But I have read a few decent arguments in favor of using it.
Great feedback -- I'll respond to one at a time and go from there.
Yes -- we should be able to do something like the following inside our package.json:
Or if
test_static_controller
expects a regular .eslintrc file -- then we can use that naming convention for the es5 (or adjust the test).What do you think?
test_static_controller
callsvalidate_js
which calls the lint command. It currently runsnpm run eslint
plus additional parameters. It'd be fine to specify the es5 file as one of the parameters there.force pushed to hs/8035
(I still need to look at the one-var setting)
force pushed to
hs/8035