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've started to use closure compiler and still hittin lot's of obstacles:)
I'm looking for the option that will output the list of removed methods/properties whatnot during the optimisation done by compiler - this would help me a lot when debugging the code.
There is no default option that lists removed symbols.
This should be possible by using a tool to highlight all of the lines that have mappings in a generated source map. Any line that has no mapping was dropped as dead code.
However I have not stumbled across a tool that would do this. It would be highly useful though and not specific to Closure-compiler.
For the past few days, I've been trying to add properly Meteor's CSP package, browser-policy. So far, I followed these ressources:
https://dweldon.silvrback.com/browser-policy
https://themeteorchef.com/snippets/using-the-browser-policy-package/
Things were a bit rough at the beginning but we are close to something, the last piece of the puzzle being live-chat Zopim's widget not being a fan of our new policy. I tried to whitelist and put zopim's widget code into a Meteor.startup call somewhere but it still fails on load due to some unsafe-eval as you can see below.
As I don't want to loosen up more my policies, is there any workaround for this or should I just forget about Zopim and give a shot at some other tool (which I'd be glad to hear about if you have any suggestion).
Bonus: Also, I first had my policy with BrowserPolicy.content.disallowEval(); but MDG's underscore package started to fall appart and I had to allow it. Allowing eval is clearly not ideal and I'd be glad to hear any alternative.
Your're hitting the first bullet point from the "issues" section of my post. You have to decide if disallowing eval is more important to you than that particular 3rd party script. In our case, we allowed eval for a few days while the external script was modified (fortunately the creator agreed to the change). It never hurts to send an email and just explain that you think their scripts are posing a risk to your site because you can't enable a strict content security policy.
We currently have BrowserPolicy.content.disallowEval() set and haven't run into any issues. I find it hard to believe that a core package would violate that directive. Maybe some other package is causing it, but it's hard to say without a detailed analysis of your dependencies.
Recently, I've noticed strange behavior by Subversion. Occasionally, and seemingly randomly, the "svn up" command will wreak havoc on my CSS files. 99% of the time it works fine, but when it goes bad, it's pretty damn terrible.
Instead of noting a conflict as it should, Subversion appears to be trashing all incoming conflict lines and reporting a successful merge. This results in massively inconvenient manual merges because the incoming changes effectively disappear unless they're manually placed back into the file.
I would have believed this was a case of user error, but I just watched it happen. We have two designers that frequently work on the same CSS files, but both are familiar and proficient with conflict resolution.
As near as can figure, this happens when both designers have a large number of changes to check in and one beats the other to the punch. Is it possible that this is somehow confusing SVN's merging algorithm?
Any experience or helpful anecdotes dealing with this type of behavior from SVN are welcome.
If you can find a diff/merge program that's better at detecting the minimal changes in files of this structure, use the -diff-cmd option to svn update to invoke it.
It may be tedious but you can check the changes in the CSS file by using
svn diff -r 100:101 filename/url
for example and stepping back from your HEAD revision. This should show what changes were made , at what revision and by whom. It sounds like a merging issue I've had before but unfortunately I found myself resolving it by looking at previous revisions and merging them manually too.
Sometimes it is convenient to "keep going" when importing lots of content, ignoring tracebacks and other failures that may occur with certain content.
Is there any generic mechanism in Transmogrifier to make this easier? The only approaches I can see are:
Use only custom blueprints that try/except where appropriate.
Use a wrapper to execute the pipeline that changes the source blueprint input to be one-after-the-failure each time.
Neither of these appear particularly convenient or desirable, hence my question.
you only need to write one blueprint which will handle and ignore all "tracebacks" you might want. be sure to put it right after "source" blueprint and yield in try/except block.
...
def __call__(self):
for item in self.previous:
try:
yield item
except Exception, e
# here do with exception whatever you want
pass
I am aware that this is not a real workaround for that (common) issue, but here's my only solution: i use a lot of pipeline steps, each that make a single, well known, change to my items. If there's a step that i fear that can cause trouble i add a condition step (collective.transmogrifier.sections.condition) and simply drop potentially bad items. I think that a real solution could be to change the way the pipeline runner call each step, it should be responsible for managing exceptions in a customisable way. If someone else has a better solution i'm interested, me too.