Does anyone know whether the open source NPM implementation allows me to implement and host my own private repository system without forking npm? Or is npm (and thus node and iojs) hard-tied to npm, Inc's proprietary offering for private modules?
Yes, the registry url is configurable. As of npm 2.x, you can also specify a different registry url for specific scopes, so for example, `@foo/bar` can live at a different registry than `@baz/boo`. "Global" packages (ie, those without a scope designator) are always fetched from the top-level "registry" config.
One of our DevOps guys setup Nexus to serve npm packages. It both allows for the publishing of private repos (meaning you get semantic versioning support unlike git links) and caching of public repos from npm. It works extremely well.
You had to add users' authorization information from their .npmrc manually to sinopia's YAML configuration file and reloading of the application. This was a showstopper.
NPM Enterprise' github authorization module requires an access token in the user's .npmrc file, but no modification to the actual running app to add/remove new users: they just have to configure their .npmrc correctly (by default, if a user has read access to the github repository referenced by the repository field in the package.json, they can install the package - if they have write access, they can publish it too). No fiddling with sending someone's NPM credentials around the network, inserting them in a YAML file and restarting the registry application.
It was six months ago that we looked into it, though, so it may have improved since then.
We also looked at using nodejitsu, but their administrative portal was abysmal, their billing buggy, and reliability unimpressive. All of which explains the godaddy purchase ;)
I don't know much about this, but our sysadmin reports that Sinopia has a pluggable authentication system, and that we ended up writing our own plugin that uses PAM (and thus system accounts) underneath.
The auth token you need locally in your own .npmrc is added automatically when you do "npm login".
That's new, then. When we were looking at it, you had to supply the npm auth token to the yaml config: it was just plaintext checking against its list of available logins.
We wanted something available "now," not "in a bit, after we write an auth plugin for it."
