[Request] Consider adding a .jshintrc or .eslintrc to V2 for contributors

[joshuafcole]

One of the simplest ways to help a larger library stay readable is to make sure its whole codebase is written in a consistent style. Tools like jshint/eslint and jsbeautifier are a way to smoke test various aspects of the codebase before a PR even occurs, freeing the maintainer to focus more on the code's behavior and less on the way the contributor writes. JSHint in particular is also excellent at catching subtle errors ranging from typos to unsafe assumptions.

I've found that jsbeautifier is somewhat intrusive what it considers right and wrong, but jshint/eslint is very configurable and tends not to be pleasant to work with. I would recommend going with at least one or the other of jshint/eslint to help guide contributors on how to write their code for the project.

[dsferruzza]

Hi!

I like JSHint.
And you are totally right: JSHint's configuration should be put in a .jshintrc file, so it would work no matter how it is launched.

About jsbeautifier, I knew the website, but I didn't know there was a npm module.
I'm using jscs on another project.
I'm OK about using a module of that kind during build, but I'm not very motivated right now to configure one...
I prefer not to spend time on that for now, but maybe you could do a PR on that when #12 will be closed and we'll have a good build task implemented.

[dsferruzza]

Well I was not sure so I checked: I use default JSHint configuration on v2 for now.
So I guess no need for a .jshintrc...
But definitely a good idea to keep in mind!

[joshuafcole]

Sure thing. I've just recently done this with Gulp, but I'm pretty sure it won't be any harder with Grunt.

[dsferruzza]

I used Grunt on v1, but I choose to switch to Gulp for v2, so it'll be on Gulp ;)

[joshuafcole]

haha, great! I'd be happy to help you get browserify and jshint or eslint
set up for you if you'd rather focus on the core.

While we're talking sweeping build suite changes, have you considered any
testing alternatives besides QUnit? I feel less strongly about this than I
do about a code quality harness and file separation, but I think the syntax
of mocha [1] tests with chai [2] assertions is a little more friendly and
organized.

here's an example suite of unit tests for a little module I wrote a while
ago:
https://github.com/joshuafcole/indeks/blob/master/test/unit/indeks.js

[1] http://visionmedia.github.io/mocha/
[2] http://chaijs.com/

On Fri, Jul 11, 2014 at 5:28 PM, David Sferruzza [email protected]
wrote:

I used Grunt on v1, but I choose to switch to Gulp for v2, so it'll be on
Gulp ;)

—
Reply to this email directly or view it on GitHub
#13 (comment)
.

Screw the environment. Please print this email immediately. And then burn
it.

[dsferruzza]

I did it: 09e8799