Sunday, June 2, 2024
 Popular · Latest · Hot · Upcoming
132
rated 0 times [  136] [ 4]  / answers: 1 / hits: 5999  / 10 Years ago, mon, october 20, 2014, 12:00:00

I've been developing a lot of small web development projects in various IDEs, and find myself laboriously typing in jslint configuration headers to silence JSLint. Its warnings and errors are all valid, and I want to keep JSLint in my work cycle, but I spin up 2-3 isolated environments a day, sometimes from generators in Yeoman, other times by hand. These all end up with gripes from JSLint that require the following in every .js file:



/*jslint browser:true*/
/*global require,yada,yada,yada*/


JSHint has a wonderful feature whereby you can declare all these in a parent folder using the body of the .jshintrc file. Does JSLint have something like this? It seems like such an obvious addition, but I can find nothing like this which will work across IDEs (Visual Studio, IntelliJ, Brackets, Sublime Text,...).



I found this for .NET, but I find Visual Studio heavy for projects I might only spend a couple hours on and then throw away (https://jslintnet.codeplex.com/wikipage?title=JSLint.NET%20Settings).



Does someone have some insight on this?



Edit: (See my new answer below.)


More From » jslint

 Answers
1

While the previous excepted answer is an excellent one (and many thanks to its author for making it even better over time!), the world has moved on from JSLint. I'd recommend to anyone reading this very old question that you seriously consider chucking JSLint out of your development cycle in favor of its very effective successor, ESLint. For an even better experience, I'd suggest taking a hard look at the ES7 vs. TypeScript paths, with TSLint being your best option for TypeScript linting.



However, for the development experience that trumps even these modern libraries, go directly for Prettier.js. With Prettier, your linting woes become irrelevant, since Prettier will rewrite your code in an opinionated manner every time it's run.



For the best results with Prettier, add the packages lint-staged and husky to your dev-dependencies, then add the following in your package.json:



husky: {
hooks: {
pre-commit: lint-staged
}
},
lint-staged: {
*.{js,json,css,md}: [
prettier --write,
git add
]
},


This will force Prettier's auto-linting behavior to run every time Git's commit command runs.



I can't tell you what a relief using Prettier has been for the front-end development teams and projects I am responsible for. We've gone from code reviews bleeding with linting correction comments to zero almost immediately. Feedback from the teams has been universally positive.



The only modification I've made has been to the tabs-vs.-spaces setting. I've modified my .prettierrc.json file to select tabs instead of spaces, because use of spaces at different widths causes dirty git merge histories. You can't control the indentation of 250+ developers spread over multiple hemispheres, some of whom drop in and out of the project before you even know their names. So, setting tabs as the default indentation allows all of the developers to operate with the indentation they're comfortable with without modifying lines in Git. Here's my .prettierrc.json file, with some other slight modifications:



{
arrowParens: always,
bracketSpacing: false,
singleQuote: true,
useTabs: true,
trailingComma: none
}

[#41793] Saturday, October 18, 2014, 10 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.
pranavrorys

Total Points: 466
Total Questions: 87
Total Answers: 115

Location: Barbados
Member since Sun, Nov 27, 2022
2 Years ago
pranavrorys questions
Fri, May 27, 22, 00:00, 2 Years ago
Thu, Oct 28, 21, 00:00, 3 Years ago
Sat, May 30, 20, 00:00, 4 Years ago
Fri, Dec 20, 19, 00:00, 5 Years ago
;