From ea7e2940c9730b41d23dacf936851eb63a916ce0 Mon Sep 17 00:00:00 2001 From: Alex Kocharin Date: Wed, 22 May 2013 11:46:36 +0400 Subject: [PATCH 1/4] Update README.md --- README.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 21d8a6d20..5c4e6947b 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,4 @@ -# Disclaimer - -I don't know the internal npm stuff yet, so if npm repository heavily depends on some complex CouchDB functions, this unive^W project is doomed. - -# Goals +## Goals We want to create a private/caching npm repository server. The idea of it to be as simple as it could possibly be, which means "just download and run it". As I recall, there're no such things available now, is there? @@ -12,19 +8,23 @@ There's two obvious use-cases: 2. Caching. If you have more than one server you want to install packages on, you might want to use this to decrease latency (presumably "slow" npmjs.org will be connected to only once per package/version) and provide limited failover (if npmjs.org is down, we might still find something useful in the cache). -# Name of a project +## Disclaimer + +I don't know the internal npm stuff yet, so if npm repository heavily depends on some complex CouchDB functions, this unive^W project is doomed. + +## Name of a project Now it's "npmrepod" for "npm repository daemon". Better name suggestions are very much welcome. :) By the way, is it called "repository" or "registry" anyway? -# Configuration +## Configuration It should be able to work without any configuration, just install and run it. Of course for some advanced usage a configuration file would be necessary. So it'll probably be a javascript or yaml config. We would want to include custom functions there as plugins, so... yeah, it's probably javascript file. -# Using public packages from npm.js / caching +## Using public packages from npm.js / caching If some package doesn't exist in the storage, server would forward requests to npmjs.org. If npmjs.org is down, we would serve packages from cache pretending that no other packages exist. We would download only what's needed (= requested by clients), and this information would be cached forever. @@ -32,11 +32,11 @@ Example: if you successfully request express@3.0.1 from this server once, you'll Open question: can we track package changes on npmjs.org without replicating their entire database? -# Features +## Features For now I'm planning to make `npm publish` and `npm install` work with this repository. Advanced features like `npm search` are so to speak not a priority. -# Access control +## Access control It is supposed to be private repository. We can't allow just anybody to see/download any package as it is in npmjs.org. So it's an open question how access control should be implemented. @@ -44,7 +44,7 @@ Maybe configuration would be simular to gitolite with working groups and such. Should we allow anybody to publish any package by default? Should it be configurable? Shall we use users from npmjs.org or use our own user management? Well... those questions are up. -# Storage +## Storage No CouchDB. It is supposed to work with zero configuration, so filesystem would be used for storage by default. @@ -52,12 +52,12 @@ But our company would want to use MongoDB for ourselves, because we have several So, we would implement some kind of plugin system. There would be at least two plugins with the package (filesystem as a default, mongodb), but if someone wants to use CouchDB or whatever he could write a plugin himself. -# Plugins +## Plugins - storage (filesystem, database) - logging (bunyan interface?) -# Existing things +## Existing things - npm + git (I mean, using git+ssh:// dependencies) - most people seem to use this, but it's a terrible idea... *npm update* doesn't work, can't use git subdirectories this way, etc. - shadow-npm (https://github.com/dominictarr/shadow-npm, http://shadow-npm.net/) - it uses the same code as npmjs.org + service is dead From 6379f7dfac3a78e055acf6c4a51545ffe04abc5d Mon Sep 17 00:00:00 2001 From: Alex Kocharin Date: Wed, 22 May 2013 16:47:45 +0400 Subject: [PATCH 2/4] Update README.md --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 5c4e6947b..246db5f0e 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,5 @@ +**This thing doesn't work yet, come back in a few weeks** + ## Goals We want to create a private/caching npm repository server. The idea of it to be as simple as it could possibly be, which means "just download and run it". As I recall, there're no such things available now, is there? From f99a9a8d18fd58923baf0655ae54caf5a9d89f87 Mon Sep 17 00:00:00 2001 From: Alex Kocharin Date: Wed, 22 May 2013 16:56:36 +0400 Subject: [PATCH 3/4] Update README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 246db5f0e..37f2b45d0 100644 --- a/README.md +++ b/README.md @@ -50,13 +50,13 @@ Should we allow anybody to publish any package by default? Should it be configur No CouchDB. It is supposed to work with zero configuration, so filesystem would be used for storage by default. -But our company would want to use MongoDB for ourselves, because we have several servers with MongoDB replication set up. +But our company would want to use MongoDB+GridFS for ourselves, because we have several servers with MongoDB replication set up. So, we would implement some kind of plugin system. There would be at least two plugins with the package (filesystem as a default, mongodb), but if someone wants to use CouchDB or whatever he could write a plugin himself. ## Plugins -- storage (filesystem, database) +- storage (filesystem, mongo) - logging (bunyan interface?) ## Existing things From 47b5f0985d4222db1d2e109620d1b7ce01dfd970 Mon Sep 17 00:00:00 2001 From: Alex Kocharin Date: Sat, 25 May 2013 19:33:54 +0400 Subject: [PATCH 4/4] Update README.md --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 37f2b45d0..3eaa5f2f1 100644 --- a/README.md +++ b/README.md @@ -62,8 +62,9 @@ So, we would implement some kind of plugin system. There would be at least two p ## Existing things - npm + git (I mean, using git+ssh:// dependencies) - most people seem to use this, but it's a terrible idea... *npm update* doesn't work, can't use git subdirectories this way, etc. -- shadow-npm (https://github.com/dominictarr/shadow-npm, http://shadow-npm.net/) - it uses the same code as npmjs.org + service is dead -- http://www.gemfury.com/l/npm-registry and others - those are closed-source cloud services, and I'm not in a mood to trust my private code to somebody (security through obscurity yeah!) +- [reggie](https://github.com/mbrevoort/node-reggie) - this looks very interesting indeed... I might borrow some code there. +- [shadow-npm](https://github.com/dominictarr/shadow-npm), [public service](http://shadow-npm.net/) - it uses the same code as npmjs.org + service is dead +- [gemfury](http://www.gemfury.com/l/npm-registry) and others - those are closed-source cloud services, and I'm not in a mood to trust my private code to somebody (security through obscurity yeah!) - npm-registry-proxy, npm-delegate, npm-proxy - those are just proxies... Anything else?