JSLint should assume browser by default

[howderek]

I believe since the main usage of Brackets is "Coding the Web" that JSLint should have browser: true set by default. Since client-side javascript is what will be used mostly in Brackets, if people want to use it for something like node.js, they should have to use /* jslint browser: false */ to have JSLint complain about there being objects like document

[njx]

Reviewed--good suggestion (kind of surprising we don't already do this). Marking starter bug for anyone who wants to pick it up.

[peterflynn]

We should be careful of the potential confusion though: this will mean the results of running JSLint within Brackets differ from the results of running JSLint in a build script, Grunt task, jslint.com portal, etc.

[daleharvey]

+1

It would be nice to have files walk back to find .jshintrc files as well as pick up ~/.jshintrc and merge them

[etrepum]

👍 – this would make a big difference to me, we're going to be using Brackets this semester at Mission Bit to teach first time programmers HTML/CSS/JS. I would love for the defaults to be appropriate for web development with no configuration.

[njx]

As of our next release (any day now...), it will be possible to set default jslint options in user preferences (there isn't a UI for it - you have to hand-edit a JSON file - but you could set that up for students beforehand). Would that be good enough?

[etrepum]

It's better, but not ideal. We want the students to be able to install Brackets (and everything else we use) themselves so they know how to do it at home or elsewhere.

[shamrin]

The other alternative is to detect when JavaScript is definitely written for the browser. E.g., when Live Preview is used. Or when .js is linked from .html file.

It's not the only problem with JSLint on Bracket. Other problems:

• it hates 2 spaces indent
• it wants "use strict" in every function
• no visual distinction between errors and warnings

Do you want separate issues for these?

[njx]

@shamrin - The first two are just more options that you would set through whatever mechanism we would create for jslint options, so I don't think they need to be tracked separately. The third is more like a usability improvement for the output, so that would make sense as a separate feature request - thanks.

@etrepum - I'll bring this up for bug review again - I think our only hesitation was the point @peterflynn made above, that setting defaults would make it inconsistent with what happens if you run jslint from grunt, etc. by default (and would be wrong for, say, node JS files). OTOH browser JS is the 80% case.

[dangoor]

I think that assuming browser by default makes sense for Brackets, especially now that there's an easy way to override that behavior.

@shamrin you don't need "use strict" in every function if you put it at the top of the file.

[etrepum]

@dangoor putting 'use strict' at global scope isn't a great practice for browser JS due to concatenation issues… of course, you can wrap everything in a function, but that's not necessarily beginner friendly either since it makes introspection trickier.

[dangoor]

@etrepum oh yeah, you're right of course. I've gotten so used to using a module system that I've tuned out the function wrapper

[peterflynn]

I'd still argue that by default we should match what all the other JSLint tools do by default -- at least until we have an easy, clear UI for changing linter settings. (Our current semi-hidden prefs file documented only on our wiki doesn't seem obvious enough for that, IMHO...)

[etrepum]

It's not obvious to me that the defaults for an app that ships with top-level HTML/CSS/JS IDE functionality out of the box should be the same defaults of a command line tool for the node.js community. I suspect that most users of Brackets are going to be doing UI work and those that aren't are more likely to know how to tweak a configuration file or be willing to understand things like /*jslint browser:false*/

[dangoor]

👍 People developing for the browser are the core audience, so it seems to me that the defaults should suit them.

[njx]

Reviewed - we agreed to go ahead with this. To @dangoor

[redmunds]

Fixed. Closing.