I want to implement stylelint in my project. I came across "stylelint-config-recommended".
But after the first lint attempt, I got 100s of errors. I don't want to use all of the rules from the package "stylelint-config-recommended". Is there any way to just pick the top 10 or most commonly used rules for CSS linting from the package "stylelint-config-recommended"?
There isn't a way to determine the top 10 or most commonly used rules.
You can turn off the rules that are producing the most warnings and revisit them at a later date. The rules that remain turned on will stop new problems from being introduced into your code.
As an aside, the Stylelint team recommends extending the stylelint-config-standard which build on top of the stylelint-config-recommended package to help you write modern CSS that's consistent with the majority of the code examples found in the specifications.
For example, to extend the standard config and turn off the no-descending-specificity rule you can use:
{
"extends": ["stylelint-config-standard"],
"rules": {
"no-descending-specificity": null
}
}
I am using lots of global constant variables and I don't want to ignore them all one by one, they all start with TXT_, and I'd like to know if it's possible to tell my JSHint in the .jshintrc to ignore those.
Unfortunately, JSHint doesn't support custom rules. There is a thread asking for this functionality, but the latest activity was 4y back. ESLint was created exactly with this purpose and it also supports all the rules from JSHint, but it way more flexible.
Please check this rule and see if it helps you.
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.)
I think the quick answer is that setting global settings for every file you JSLint is the job of your IDE or favorite text editor. That is, JSLint is essentially just a big javascript file. It doesn't care about file paths, etc, and won't look for a server-wide config.
I mean, you can change the options used when JSLint is called, but that essentially reduces to the same problem you have now.
So then the question is, if you don't like Visual Studio, what tools do you use? In VS, I've used this tool and liked it a good deal. I think that's different (as in not forked or related, but I could be wrong) than the one you found. In Sublime Text, there are two. I've been using Darren Deridder's, but I get the impression that it's the less popular of the two. Etc etc.
So this isn't a javascript/JSLint question so much as a JSLint wrapper question.
It should be said that JSLint's code is very clean, and it's easy to rig up your own process using Node or something similar. I've done it with JavaScript.NET, though I'd use Node if I was doing it again.
And I'd also suggest you consider keeping the file-by-file JSLint headers. I tend to do so, and it keeps your use "excuses" to a minimum, keeping your code tighter. It's way too easy to get a giant /*global ...*/ header line, for instance, if you have a lot of shared config info. It also means that when someone else uses a "shell" tool different than yours to JSLint your files, you know they're using pretty close to your intended accepted behaviors.
So the literal answer to your question is, "No, JSLint doesn't inherently support a box-wide config file." The longer answer is, "Tell us where you do like to work." ;^)
EDIT: Debated staying out of the usual 'Hint vs. 'Lint discussion, but I will quickly say I like how you're thinking. JSLint is more draconian, but JSLinted code means something more specific than code that's been JSHinted. I won't argue that more specific means better, per se, but I will say that I see JSLint's draconian-ness to be an advantage. It might not be the only way to do something, but there's nothing that Crockford's telling you that's a bad idea, and it's nice to get familiar with those conventions. In the parlance of my times, Crockfords's not wrong, Walter.
EDIT 2: So Brackets looks like it's come a long way since I last used it. Seems to have JSLint by default.
It looks like you can set global JSLint options using the jslint.options setting in your preferences file (and there might be/have been a goal to make that a more interactive UI eventually), like this...
{
"debug.showErrorsInStatusBar": false,
"styleActiveLine": true,
"jslint.options": { "sloppy":true, "white":true, "browser": true }
}
And it does allow settings at the top of the file to override these settings.
This really is approaching a golden age of text editors. I still fall back on VIm a lot, but mainly live VS and Sublime Text, with even jEdit, Coda, and PhpStorm for specific tasks. Looks like this might be my new Sublime for Node & html frontend dev. The quick CSS edit is wonderful, though bindings will complicate it. Thanks!
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"
}
I'm doing some class extensions in Less, but it's silently failing if the class I attempt to extend isn't found. I'd really like to see a warning about that. Is there a way to enable it?
.foo {
&:extend(.bar); // .bar is undefined, fails silently
}
Less emits "extend fails" warnings by default since v2.3.0. Though by the time I'm writing this, only lessc itself shows these warnings. Other tools (e.g. gulp-less, grunt-contrib-less etc., i.e. those that use the Less library programmatically) need to explicitly implement a dedicated support for such warnings (there was no "warnings-facility" in Less before) and so far none actually did this yet.
SHORT: Is there a possibility to import less files "on demand", only when the function/variable has not been defined yet?
LONG: Let's assume I have LESS file containing my styles for the page. Let's call it styles.less. In addition, I have 5 more LESS files. Everyone of there contains generic design primitives, for example design of the info box which I use in many projects - that's the reason it's not been merged to styles.less. Let's assume it's called .infobox {}.
Then, is it somehow possible to "try" to import that 5 files when .infobox is not found in styles.less? I'm interested in both compiling via lessc (module for node) and "on-the-fly" compilation in web browser.
I hope my examples clarify the situation enough - if not, feel free to comment and I'll edit the question to provide more information.
I have not been able to find a way to make this fully automated. I also do not know if you are desiring this functionality in order to reduce #import requests or to simply reduce the final CSS to not load items it does not need.
If you do not need it to be fully automated, and you are seeking just to reduce the CSS generated, and you do not have too many classes you desire to do this with, then you can do something like the following in your styles.less file.
//have at the top of the file some variables set to 0 or 1 if the class
//is present or absent in that file
#usesClass-infobox: 0;
//set up a mixin to load it if NOT in the file
.setClass-infobox(#set) when (#set = 0) {
#import 'infobox.less';
}
//a default mixin to do nothing otherwise
.setClass-infobox(#set) {}
//call the mixin
.setClass-infobox(#usesClass-infobox);
Of course, this does not really help automate the process. After all, if you know .infobox is not in the styles.less file, then you would just add the #import anyway without any extra mixins to check. The only real value this gives is that it sets up a section of variables that basically informs the coder that "Hey, there are modules that can be loaded for this functionality if you are not including it here; so tell me, are you including it?"
Again, I'm not sure if this totally resolves what you are going for. I offered it as it could be useful for some people in some situations.