The document provides an overview of the Node Package Manager (npm). It discusses how npm works to reduce friction in the software development process by making it easy for developers to install packages and dependencies without conflicts. It describes npm's vision of avoiding "dependency hell" and its strategies for achieving this like ensuring consistent interfaces and reducing excessive metadata requirements. The document also summarizes key npm commands, how installations work, and future plans like binary distributions, an automated testing system called npat, and build farms to test packages on multiple platforms.
2. Disclaimer
• I'm going to talk about how npm works.
• It works the way I want it to work.
• There are a lot of trade-offs and paths.
• We can be different and still be friends.
3. wtf is a npm?
• If you're here, you've probably used it
• v1.0 just landed
• curl http://npmjs.org/install.sh | sh
4. Vision
To increase speed:
Either push harder, or reduce friction.
If everyone is doing one,
do the other.
5. Vision
• 2009: Lots of folks pushing hard on node.
• Wanted a way to easily install the
things people were making.
• Starting with a clean slate. Get it right.
No dependency hell allowed!
11. Inconsistent surfaces
• Before:
• clone this git repo, then run "make", then
copy this file into your .node_libraries
folder, and make sure you name it
"whatever.js", and that you have some
version of "blab" already installed there, I
think the latest version on github works.
17. Publication cabal
• aka "permission to publish"
• Sensible in the Debian world
• Not so much in Node
• Anarchic Dictatorship
18. convention vs
configuration
• Popular mantra:
Convention over Configuration
• Convention is like kids:
It has to grow up at its own speed.
• Having it before you're ready is unwise.
21. convention vs
configuration
• Perl: 24 years old
• Python: 20 years old
22. convention vs
configuration
• Perl: 24 years old
• Python: 20 years old
• Ruby: 16 years old
23. convention vs
configuration
• Perl: 24 years old
• Python: 20 years old
• Ruby: 16 years old
• Node: 2 years old
24. convention vs
configuration
• Standing on the shoulders of giants, yes.
• Impressive and important, absolutely.
• Meteorically hacker-news spamming.
• But the community is still finding its voice.
25. convention vs
configuration
• Be a pain-killer, not a vitamin, not surgery
• "Here's a package.json file" vs
"Please structure your program like this."
• Patterns that make sense for Python/Ruby
don't always make sense for Node.
26. convention vs
configuration
• Better model:
Configuration in search of convention
• Enable as much as possible,
then bless popular patterns as they arise.
• This is a process. It is organic.
27. Today...
• almost 1900 projects from
775 active package authors
• Too many to list in a lunch
(even if you're Marak)
• ~300 new packages per month
~2000 updates per month
28. Today...
At the next NodeConf,
I will show you that last slide.
You will say, "So few?"
31. The Registry
• A Couchapp:
• http://isaacs.ic.ht/registry
• https://github.com/isaacs/npmjs.org
• JSON: http://registry.npmjs.org/
• HTML: http://search.npmjs.org/
32. The Registry
• Tarballs are attachments to package docs
• "npm adduser" to auth
• "npm owner" to manage ownership
• CouchDB rocks for this.
33. Behind the Firewall
• Several companies running their own
internal registries.
• "private":true
• "publishConfig" :
{"registry":"http://internal"}
• Replicate from the public reg (if you want)
34. anarchic dictatorship
• If you publish it, it's yours.
• Land-grab for names.
• Authors admin their own stuff,
simple permission scheme
35. anarchic dictatorship
• Packages get abandoned
• Authors go awol
• Programs can be malicious or misleading
• Having a server admin is important
<i@izs.me> (don't be creepy)
36. The cache
• In ~/.npm, registry items are cached.
• ETags FTW!
37. new in 1.0
• *vastly* simplified folder structure
• Smarter .gitignore/.npmignore handling
(ie, it works how you think now)
• global vs local installation
38. new in 1.0
• *vastly* simplified folder structure
• Smarter .gitignore/.npmignore handling
(ie, it works how you think now)
• global vs local installation
39. global vs local
• Any command: add `-g` to do it globally.
• Local by default ("always bundle")
40. global vs local
• Global goes in /usr/local
• Local goes in $PWD/node_modules
41. global vs local
• Global for putting bin files in the PATH
• Local for require()
42. global vs local
• Global root is not in node's require path.
• Local root is.
46. Scripts
• Hash of {<event>:<command>}
• npm runs scripts as "nobody" if you're root
• prefoo, foo, postfoo
• The env has all KINDS of data.
47. Scripts
(The Important Ones)
• install: When your package is installed.
• start: How to start your server.
• test: Run by the `npm test` command.
• prepublish: Before publishing
48. Scripts
• Definitely include a "test" script.
• npat! You will super <3 this!
• (Also, tests make you look like a grown up.)
49. commands
• Files in npm's source as lib/<cmd>.js
• Hang on the npm object at
npm.commands.<cmd>
50. commands
• Pretty big CLI app in Node.js
• npm completion
• npm install -h
• abbrev support
51. install
• If you only know a single npm command,
this is the one to know.
• With no args:
Install deps locally, run build scripts
52. link
• "I want to make changes to node-foo lib,
and have all my projects always see the
latest code."
• "I want to make changes to node-foo cli
app, and always have `foo` run the latest
code."
54. ls
• Displays installed packages
• ls -g -- List global packages
• ls -p -- List in parseable format
• ls -l -- List in "long" format (more data)
• Combine 'em: ls<rimshot>
still MIT licensed, though
-gpl
55. npm reusable team
• Pieces spun off as standalone projects:
• nopt - the option parser
• semver - the version thingie
• abbrev - like ruby's Abbrev
• More coming soon!
57. bindist
• On publish, pre-compile binary addons.
• Required for eventual Windows support
• Experimental, but working surprisingly well.
• (probably hideously broken somehow)
58. npat
• npm Package Testers
• Inspired by Perl's CPANTs, the best damn
distributed CI testing system yet devised.
• Ours will be even better, because CPANTs
wasn't built in a world where CPANTs had
already been built. :)
59. npat
• To get on the bandwagon:
npm set npat true
• installs devDependencies and runs tests
• Fail fast! Fail hard!
(Then install with --no-npat )
60. npat
• Results will be uploaded to a database
• "Which platforms should I care about?"
• "Which packages work on my platform?"
• Npat will tell you.
61. Build Farms
npat reports +
binary distributions +
servers in multiple operating systems =
Ultimate Package Test Integration Mega Engine
62. Build Farms
npat reports +
binary distributions +
servers in multiple operating systems =
Ultimate Package Test Integration Mega Engine
63. Build Farms
npat reports +
binary distributions +
vm's in multiple operating systems =
Ultimate Package Test Integration Mega Engine
64. Build Farms
npat reports +
binary distributions +
vm's in multiple operating systems =
Ultimate Package Test Integration Mega Engine
65. Build Farms
npat reports +
binary distributions +
vm's in multiple operating systems =
Ultimate Package Test Integration Mega Engine
67. Build Farms
• Build everything as it's published
• Publish bindists back to the registry
• Run tests and upload results
• Seriously, it's gonna rock
68. How you can help
• Keep building awesome stuff with Node
• Open-source your reusable libraries
• Publish to the npm registry
• Help out with some of that future stuff
• Provide feedback, find bugs, help n00bs