THERE’S SOME GUIDELINES… • Very small, focusing on a single task • Client-side bundling via browserify • Repository name matches npm package name • Add a README.md file • Add unit tests, with “cloud testing” enabled
SMALL, FOCUSED • Must export a Function: module.exports • Helps enforce the small and focused philosophy • Example: https://github.com/webmodules/node-contains
SMALL, FOCUSED • If a module has an inverse function, implement it as a separate module / repository • Example: https://github.com/webmodules/wrap-range and https://github.com/webmodules/unwrap-range wrapRange(‘b’) → unwrapRange(‘b’) →
BROWSERIFY • Assume browserify will be used for client-side bundling • It’s possible that other bundlers like component or require.js might work in some cases, but untested
GITHUB == NPM • Make it easy for users to find the repository • Basically leaves us at the 2nd level namespace, since most of the good single-word names are taken in the npm registry at this point
CLOUD TESTING • Travis-CI • Use it to run SauceLabs browsers in the cloud • Set up GitHub commit hooks to test every commit • https://github.com/defunctzombie/zuul/wiki/Travis-ci
CLOUD TESTING • SauceLabs • Zuul is designed to integrate with Saucelabs • Somewhat annoying… you have to create a new SauceLabs account for every module created