Skip to content
This repository was archived by the owner on Sep 6, 2021. It is now read-only.
This repository was archived by the owner on Sep 6, 2021. It is now read-only.

JSLint should assume browser by defaultΒ #3269

Closed

Description

@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

Activity

  1. njx commented on Apr 1, 2013

    @njx

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

  2. peterflynn commented on Apr 1, 2013

    @peterflynn
    Member

    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.

  3. daleharvey commented on May 7, 2013

    @daleharvey

    +1

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

  4. etrepum commented on Jan 22, 2014

    @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.

  5. njx commented on Jan 22, 2014

    @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?

  6. etrepum commented on Jan 22, 2014

    @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.

  7. shamrin commented on Jan 22, 2014

    @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?

  8. njx commented on Jan 22, 2014

    @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.

  9. dangoor commented on Jan 22, 2014

    @dangoor
    Contributor

    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.

  10. etrepum commented on Jan 22, 2014

    @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.

  11. dangoor commented on Jan 22, 2014

    @dangoor
    Contributor

    @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

  12. peterflynn commented on Jan 23, 2014

    @peterflynn
    Member

    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...)

  13. etrepum commented on Jan 23, 2014

    @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*/

  14. dangoor commented on Jan 23, 2014

    @dangoor
    Contributor

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

  15. njx commented on Jan 23, 2014

    @njx

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

  16. ghost assigned on Jan 23, 2014
  17. redmunds commented on Jan 30, 2014

    @redmunds
    Contributor

    Fixed. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions