You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 6, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 6, 2021. It is now read-only.
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
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.
π β 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.
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?
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.
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:
@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 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.
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...)
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*/
Activity
njx commentedon Apr 1, 2013
Reviewed--good suggestion (kind of surprising we don't already do this). Marking starter bug for anyone who wants to pick it up.
peterflynn commentedon Apr 1, 2013
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 commentedon May 7, 2013
+1
It would be nice to have files walk back to find .jshintrc files as well as pick up ~/.jshintrc and merge them
Add support for project-wide JSLint config.
Add support for project-wide JSLint config.
etrepum commentedon Jan 22, 2014
π β 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 commentedon Jan 22, 2014
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 commentedon Jan 22, 2014
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 commentedon Jan 22, 2014
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:
Do you want separate issues for these?
njx commentedon Jan 22, 2014
@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 commentedon Jan 22, 2014
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 commentedon Jan 22, 2014
@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 commentedon Jan 22, 2014
@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 commentedon Jan 23, 2014
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 commentedon Jan 23, 2014
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 commentedon Jan 23, 2014
π People developing for the browser are the core audience, so it seems to me that the defaults should suit them.
njx commentedon Jan 23, 2014
Reviewed - we agreed to go ahead with this. To @dangoor
redmunds commentedon Jan 30, 2014
Fixed. Closing.