Shared publicly  - 
Code linting (JSHint, JSLint, CSS Lint... ) can run at a number of different times in your workflow: On 1) file save, on 2) source control commit, or 3) in a build process. At what point do you do it?

(I'm mostly interested in folks that have this automated, rather than it being a manual step.)
Carl Putscher's profile photoLeigh Garland's profile photoMartin Alker's profile photoAlexsandro Pereira's profile photo
@ source commit. because for testing, many of the things it will catch for me doesn't matter. although it can find some interesting mistakes at build time. I do rather like google's internal method.
Just +1 these first 3 comments if that's your answer. :)
Longer answer from Anton, author of JSHint:

i have jshint/pyflakes/pep8 on save, before creating a new differential (code review request) and during out CI test.
basically we have arc diff command to start a new code review request and it automatically lints all changed files and generates a report that both you and reviewer can see. Lint OK Lint Errors
least we have a diversity of answers. I await the flame war; vi vs. emacs style :)
pre-commit hook as well as on CI as a part of the test target
Since syntax errors are the most common source of bugs, by far, I like to get several chances to catch those errors automatically. To that end, we have automated lint going in several places:

1. Realtime in the IDE
2. On filesave (this is also when build happens at RootMusic, thanks to the stellar Hawthorn build system written by +Gabriel Hernandez)
3. At differential (code review)

This system isn't perfect yet (getting all the tools to share the same rules is still on the to-do list), but the build-step lint is canonical, and the results are seen by all the developers every time the build step gets run, so it's still a huge help.
To enforce it across an entire team (and maybe one day the entire company), we're looking at adopting practices our application developers seem to endorse which is doing syntax checking on commit and blocking those commits that fail to pass these checks. This, of course, requires a much more comprehensive VCS setup than a simple plugin for everyone's favorite editor/IDE, but it seems as though it may work to promote better standards throughout a larger team than "strong words" from leads or even a coding conventions doc.

Personally, I use JSHint on-save in TextMate to ensure I'm not doing bad things — but that's not preventing someone else from doing bad things. In a perfect world, every developer would be writing code that passed the same linting rules, but that's obviously not the case.
On save and keybound to Cmd + 1 (TextMate).

For automated jsl/hint, we're looking at using continuous integration (Jenkins) with NodeJS to jsl/hint the JS directories -- But lint errors should never get that far and should be caught in a code review!

I'm also thinking that jslint errors shouldn't cause a build failure unless you're using NodeJS as a backend. Typically I run into a lot of lint errors/warnings with community-driven plugins.
+Jaime Bueza I feel the same way about the open-source bits, but I think that the in-house stuff absolutely should stop the build. Maybe different config for each?
Agreed with just application-specific JS should cause build failures when jslint fails. If the project was using html5boilerplate, I'd probably just ignore the /js/libs/.
JSHint plugin in vim keeps us in check as we go.
Real-time in Aptana. JSLint support comes standard but you have to enable it.
I use Closure Linter, but "haphazardly" wasn't an option :)
JSLint ar saving file with the Netbeans plugin.
No need for a plugin, Alejandro. To enable it: Preferences -> Aptana Studio -> Validation -> JavaScript -> JSLint JavaScript Validator
Add a comment...