JSLint Common Settings for General use and very strict

Nov 13, 2014 at 10:55 AM
Edited Nov 13, 2014 at 10:55 AM

I am currently building against SharePoint 2013's App model and I want to avoid costly typos in my CSOM / JSOM code

I know this a bit subjective, but is there recommended settings for

1) General or pragmatic settings - general good practice and avoiding mistakes in the code so fewer warnings - all newbies should set this etc. For example, I don't want to be told about lines being too long!

2) Uber strict - lots of warnings



Nov 13, 2014 at 7:14 PM
Edited Nov 13, 2014 at 7:16 PM
Great questions.
  1. I'm going to have to fall back on "it all depends" I'm afraid. JSLint (and therefore JSLint.NET) has all options undefined by default - including the line length limiter - so I would start there. But the realities of your environment may require some tweaking and tolerating some things.
    For example, if you work a lot with third party libraries, it's likely you have no control over callback / event handler signatures. In that case, turning on "unparam" toleration is likely to be necessary.
    Again, the maximum line length option is undefined by default.
  2. JSLint is somewhat "uber strict" regardless. But there are some toleration options that I would never recommend turning on, such as "sloppy" which allows a missing 'use strict' pragma. Using strict mode makes JavaScript more robust for free.
The workflow I recommend is to start with the JSLint.NET for MSBuild NuGet package. Inside your project, include two JSLintNet.json files, one for defaults and one for Release mode. The default is set to output JSLint violations as warnings, and the Release version (JSLintNet.Release.json) output errors.

What this means is that JSLint violations will be visible during debug and development, but should not slow you down while you're actively iterating and refactoring. Once it's time to commit though, all warnings must be cleaned up, and building in Release mode (the assumption is that all CI servers do this) will ensure nothing slips through the cracks.
Nov 13, 2014 at 9:10 PM
Thanks for a thoughtful answer. I will appraise the dev team with your response when I am in the office. Also would you mind if I tweeted a link to this discussion, as I think others will find it useful.

Nov 14, 2014 at 7:59 AM
Not at all - link away.

I really want to find the time to do a video with some of these workflow tips. It's hard to explain the nuances in writing.
Nov 14, 2014 at 8:51 AM
Thanks, for lettering me know.

Perhaps there is another short term approach. Why don't you have a "Getting Started" post that has a screen dumps of the settings for the following
  • General best practice JS Development ( dev and release)
  • Working with Knockout or Angular or Node.
In the discussion dev's could comment that they use so and so settings because......

I find pictures are one way to avoid my terrible spelling in posts or emails ;-)