Add CoffeeLint about broccoli-coffee HOT 4 OPEN

+1 for CoffeeLint
+1 for option iii - But I'd say start the search at the project root instead and work down to the current working directory. A path could be set in the Brocfile too, of course. If no linting options are found I don't think someone would want any linting done.

Furthermore, I think the code should scan for a coffeelint.cson first, and then search for a coffeelint.json if a coffeelint.cson isn't found. Who wouldn't want to be able to comment on the linting options? We can comment in cson but not json.

from broccoli-coffee.

Thanks for the input @devinrhode2, I think those are good suggestions - and thanks for pointing me to cson, I hadn't come across that before. I think if you have a coffeelint.[j|c]son file in the working directory or one of its ancestor directories, that should override the project root version, no?

I think this might be a reasonable implementation pattern.

I'll try to get onto it (with the changes suggested) fairly soon if I can.

from broccoli-coffee.

On Wed, Dec 10, 2014 at 3:16 AM, Christopher Mardell <
[email protected]> wrote:

Thanks for the input @devinrhode2 https://github.com/devinrhode2, I
think those are good suggestions - and thanks for pointing me to cson, I
hadn't come across that before. I think if you have a coffeelint.[j|c]son
file in the working directory or one of its ancestor directories, that
should override the project root version, no?

Yes. Good point. Now, the question becomes, do we take the root json as a
base and merge it with the children, where the children properties
override the ancestors? I think this would be great; for example, with a
node project where you have a server and client folder. The client folder
could certainly have a little bit different lint options, as would
client/tests/ and server/tests/ folders.

I think this
https://github.com/rwjblue/broccoli-jshint/blob/v0.5.3/index.js#L102-L119
might be a reasonable implementation pattern.

I would think jshint would want a similar design, and by looking around the
issues I see multiple people would appreciate this behavior.

I'll try to get onto it (with the changes suggested) fairly soon if I can.

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

from broccoli-coffee.

Great suggestion, I'll aim for that, and maybe even fork broccoli-jshint
and apply the same.

"Be the change you want to see in the world"
-Mahatma Gandhi

On 11 December 2014 at 05:43, Devin Rhode [email protected] wrote:

On Wed, Dec 10, 2014 at 3:16 AM, Christopher Mardell <
[email protected]> wrote:

Thanks for the input @devinrhode2 https://github.com/devinrhode2, I
think those are good suggestions - and thanks for pointing me to cson, I
hadn't come across that before. I think if you have a
coffeelint.[j|c]son
file in the working directory or one of its ancestor directories, that
should override the project root version, no?

Yes. Good point. Now, the question becomes, do we take the root json as a
base and merge it with the children, where the children properties
override the ancestors? I think this would be great; for example, with a
node project where you have a server and client folder. The client folder
could certainly have a little bit different lint options, as would
client/tests/ and server/tests/ folders.

I think this
<
https://github.com/rwjblue/broccoli-jshint/blob/v0.5.3/index.js#L102-L119>

might be a reasonable implementation pattern.

I would think jshint would want a similar design, and by looking around
the
issues I see multiple people would appreciate this behavior.

I'll try to get onto it (with the changes suggested) fairly soon if I
can.

—
Reply to this email directly or view it on GitHub
<
https://github.com/joliss/broccoli-coffee/issues/10#issuecomment-66437382>

.

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

from broccoli-coffee.