Creating JS modules jakobm.com @jakobmattsson 

FishBrain is the fastest, easiest way to log and share your fishing. ! Get instant updates from anglers on nearby lakes, rivers, and the coast. 

Google: fishbrain careers 

baxter bucketful bucketful-loopia buffet-brunch cellsynt chalcogen commonjs-jquery confirm connect-rewrite dinode express-jit-coffee fn ftp-replace iota.js jakobmattsson-client-cookies jakobmattsson-cucumber jakobmattsson-serenade jakobmattsson-swfobject jscov json-request jsonrpc-http jsonrpc-http-browser-client jsonrpc-http-client-browserify jsonrpc-http-client-node jsonrpc-http-server locke locke-api locke-client locke-client-jsonrpc locke-consumer locke-store-mem locke-store-mongo locke-store-test loopia-api manikin manikin-mem manikin-mongodb manikin-tools mocha-http mocha-term-cov-reporter mongocmd nameify node-auther opra opra-compiler path-router path-router-decorator piescore plusone-mongohq plusone-nodejitsu powerfs rester rester-tools runr selenian trester underscore.plus viaduct-client viaduct-server wd-tools z-builtins z-core z-std-pack z-underscore zee Author of some modules 

Hipster or homeless? 

Hipster or homeless? 

James ”substack” Halliday 400 modules 

”But I’m a fronted dev!” ”I don’t care for Node.js!” 

Your tools do ”But I’m a fronted dev!” ”I don’t care for Node.js!” 

Your tools do You can use npm in the browser ”But I’m a fronted dev!” ”I don’t care for Node.js!” 

*previous talk by Johan Nilsson 

*previous talk by Johan Nilsson 

Creating JS modules 5 things you don’t want to miss 

#1 

#1 

package.json { "name": "z-core", "version": "0.6.0" } Then run ”npm publish” and you’re done. Collect fame and fortune. 

{ "name": "z-core", "version": "0.6.0", "description": "Utility library for JavaScript promises", "keywords": [ "promises", "util", "functional" ], "author": "Jakob Mattsson (jakobm.com)", "license": "MIT", "main": "./lib/index.js", "repository": { "type": "git", "url": "http://github.com/jakobmattsson/z-core" }, "bugs": ”http://github.com/jakobmattsson/z-core/issues", "private": false, 

"files": [ "lib", "LICENSE" ], "engines": { "npm": ">= 1.3 < 2", "node": ">= 0.10 <= 0.11" }, "devDependencies": { "mocha": "^1.18.0", "coffee-script": "^1.7.1" }, "dependencies": { "underscore": "*" }, "optionalDependencies": { "es6-promise": "^0.1.1" } } Files to be included Where does it work? Required to build/ test/etc Required to use Not required, but nice to have 

Scripts "scripts": { "test": "mocha tests/*.js", "run": "node lib/server.js", "publish": "...", "install": "...", "stop": "...", "restart": ”...", ! "prepublish": ”...", "postpublish": ”..." } 

Scripts mocha tests/*.js ! VS ! ./node_modules/.bin/mocha tests/*.js 

Remember No global installs ! Leverage the scripts-attribute ! PATH=$PATH;./node_modules/.bin/ ! 

#2 

#2 Semantic Versions 

1 . 2 . 3 Major Minor Patch 

Given a version number MAJOR.MINOR.PATCH, increment the: ! MAJOR version when you make incompatible API changes ! MINOR version when you add functionality in a backwards- compatible manner. ! PATCH version when you make backwards-compatible bug fixes. ! Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. Summary 

Note Software using Semantic Versioning MUST declare a public API. ! This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive. 

Note Major version zero (0.y.z) is for initial development. ! Anything may change at any time. The public API should not be considered stable. 

Note Once a versioned package has been released, the contents of that version MUST NOT be modified. ! Any modifications MUST be released as a new version. 

http://semver.org 

IRL Things change, break, disappear and rules are bent. ! People can’t be controlled. This is open source. ! And there are crazy rebels out there… 

No content

No content

No content

Solution!! 

Lock the version numbers "dependencies": { "underscore": ”1.4.2” }, 

No content

No content

No content

No content

Why? Bug fixes won’t propagate ! Features take longer to reach developers ! Tons of ”version bump” commits 

Follow the semantics "dependencies": { "underscore": ”>= 1.4.2 < 2”, "foobar": ”>= 0.4.2 < 0.5”, }, 

Or, simpler "dependencies": { "underscore": ”^1.4.2”, "foobar": ”^0.4.2”, }, 

Building an app? Different story… Check in dependencies or Shrinkwrap 

Keep up-to-date npmedge $ npmedge es6-promise has 1.0.0, but ^0.1.1 is specified jsontool has 7.0.2, but 7.0.1 is specified jscov has 0.6.14, but ^0.5.7 is specified chai-as-promised has 4.1.1, but ^3.3.1 is specified 

So… Use semver when versioning your module ! Mind it when you depend on something ! Use shrinkwrap and npmedge 

#3 

#3 Test it 

”I wrote some code, please maintain it” ! — Every pull request ever 

No content

Strategy Node.js AND the browser(s) ! Use two different setups ! Use the same test 

mocha 

#4 

#4 Continous Integration 

.travis.yml 

But the browsers…? Bucketful ! Chalcogen ! Sauce Labs 

Sauce Labs 

Makefile release 

So: Test all browsers in CI - not manually ! Don’t publish by hand ! Travis + Sauce Labs = *drewl* 

#5 

#5 Test Coverage 

Instrumentation Mocha recommends JSCoverage ! It does the job, but is a little messy ! I implemented a drop-replacement: jscov 

jscov 

Improve the reports? Terminal reports: mocha-term-cov-reporter ! Running with CI: coveralls ! ! 

reporting 

(#6) 

Time’s running out… makefile ! bower.js ! And more details… 

mocha chai sinon selenium sauce labs browserify bucketful chalcogen jscov mocha-term-cov-reporter npmedge coveralls travis ci jsontool 

Creating JS modules jakobm.com @jakobmattsson bit.ly/spotifyjs + -