In loop-server (and most of the fxa-* repos) we use the following: - nsp[1] - a useful tool for checking for vulnerable modules via the https://nodesecurity.io/advisories database. This is mainly a CLI tool, so we only use it locally or install it on Travis. Grunt options also available, such as "grunt-nsp-shrinkwrap" (checks a npm-shrinkwrap.json file) or "grunt-nsp-package" (checks a package.json file's dependencies, but is less performant but necessary if you aren't using shrinkwrap). We used to fail the build on Travis when we encountered a vulnerable module, but we disabled that due to lots of sub-sub-sub modules not updating. - npm outdated[2] - a handy npm-ism for checking for outdated modules which have newer versions available. Useful when combined with nsp since it can tell you if there is a newer version of a vuln module. By default `npm outdated` will search all the way through every nested sub-dependency and report any outdated modules which is a silly default behavior. You can only have it check for your top-level dependencies in your package.json file by adding the `--depth 0` flag: `$ npm outdated --depth 0`. - eslint[3] - standalone is useful for a global module locally, or it can be scripted via Makefiles. If you're using Grunt, grunt-eslint is preferable since it is easier and better (globbing, configs, etc). - travis[4] - everybody knows travis. But useful for running tests and linting code and checking for vuln modules on each commit. Not sure how/if that would work if you guys are using HG/SVN/other and 19 other intermediate build steps. - Plus we have oodles of other Grunt tasks which are extremely useful (or not, but I like them). You can see most of the magic at https://github.com/mozilla/fxa-content-server/ (feel free to ask questions). We're pretty strict, so we enforce coding styles (quotes, indenting, unused variable policies) using jscs[5] via grunt-jscs[6]. We also have linters for .JS, .JSON, .CSS, .SCSS (Sass, baby!), and HTML (as well as bonus linters to check .PO files versus a .POT schema file to check if localizations get out of sync). Plus a Grunt task to check that certain files contain a MPL copyright header. We also have a bunch of other handy scripts that auto-generate changelogs, bump package.json versions, minify+concat files, run JS code coverage, autoprefix CSS to add vendor prefixes (useful if you're running this client in multiple different browsers vs strictly FxOS or Firefox Desktop), convert markdown to HTML, and on and on and on. All of our Grunt tasks are at https://github.com/mozilla/fxa-content-server/tree/master/grunttasks [1] https://github.com/nodesecurity/nsp [2] https://www.npmjs.org/doc/cli/npm-outdated.html [3] http://eslint.org/docs/rules/ [4] https://travis-ci.org/ [5] https://github.com/jscs-dev/node-jscs [6] https://github.com/jscs-dev/grunt-jscs/

Also, a brief and poorly written blog post on using nsp+shrinkwrap+npm outdated, etc: http://nodeexamples.com/2014/08/16/checking-for-vulnerable-node-js-modules/

THis seems like a fine meta-bug for infrastructure improvements. I asked Peter to file this in particular because the nsp / npm outdated stuff, which I think is pretty important, but there are plenty more low-hanging fruit around, as he points out.

Do you guys use Travis? I found this, but it seems blank: https://travis-ci.org/mozilla/loop-client But wasn't sure if Travis is maybe not possible with your current build system. It's just a nice place to quickly to go to see latest code coverage for the tests and hide away command line tasks like running the linters to make sure everything passes ESLint/JSHint or whatever other linters you may be using.

(In reply to Peter deHaan [:pdehaan] from comment #3) > Do you guys use Travis? I found this, but it seems blank: > https://travis-ci.org/mozilla/loop-client We used it in the past, when loop-client was the authoritive repo. > But wasn't sure if Travis is maybe not possible with your current build > system. It's just a nice place to quickly to go to see latest code coverage > for the tests and hide away command line tasks like running the linters to > make sure everything passes ESLint/JSHint or whatever other linters you may > be using. IMO, until we're able to get some sort of travis integration feedback into tbpl/treeherder, or we're able to make loop-client authoritive again, this isn't going to be sensible to do - changes by developers in m-c won't be testable until they get to loop-client, so without feedback on tbpl/treeherder, we'll just be getting forever broken with long feedback loops, especially for things as sensitive as lint. Something like testing Chrome integration, I think we could and should do (there's a bug on this already), as we're much less likely to break that integration on a regular basis.

I've now set up nsp for the new loop repo, running once a day on the dev server. Most of the other items here we've already got set up. I think the main thing missing is outdated npm modules, which bug 1232793 now covers. Hence, I'm going to close this as WFM.