Great - I think so too. I'm glad you're working on this.
> 1. npm should be able to pull in all or most of the current node
> projects that are on github today, by leveraging what is common, and
> exposing it in a consistent way, without requiring that those projects
> change to accommodate npm's needs.
You don't need to worry too much about legacy code. Everyone here
knows that this is developmental and the API is fluid - at least in
the near future. If making some requirement on "packages" makes sense,
then do it :-)
> 2. npm should make it easy to use any package it can install with a
> predictable and consistent inclusion method. No matter how the
> package is set up, this should work:
> $ npm install some-node-package
> (then in my code)
> var thing = require("/some-node-package.js");
What about namespace collisions?
> 3. npm should require a minimum of metadata in order to pull in code.
> The more effort it is to create a package, the less likely that people
> will do it. Small interfaces tend to be both more stable, and easier
> to grok.
Agreed, as long as it has room to grow.
> 4. The npm package catalog should be something that we can all
> contribute to, without any one person having to manage or know about
> all the different packages out there. The package catalog should be
> separate from npm, and both should be separate from node, so that they
> can grow and change without being necessarily tied to one another.
> Some degree of intermingling is inevitable, but it should be
> minimized, not encouraged.
I would like to work towards a future where there is a specialized
authorization web app / REST interface to the catalog. Perhaps even
multiple concurrent catalogs. It would be nice if access to your flat
JSON catalog was abstracted in a way that the flat file database could
be replaced with some specialized internet database but not affect the
code. In particular, assumptions about having the entire catalog
locally stored should be avoided.
> 7. npm should encourage good practices. Currently, if your project
> uses ejs, you have to include your own ejs.js script in your project.
> That means that a bug we find someday in ejs will have to be fixed in
> multiple places. It'd be much better to have a single "ejs" package
> that npm knows about, make your project require it, and we can all
> share. (This is why not having version numbers will suck soon.
> Changing something like ejs could easily break things that depend on
Dealing with namespace collision should be a main design goal. I'm not
sure of the best way to handle this.
> Please let me know what you think. Talk about features you'd like to
> see is great, but it's less valuable to me than figuring out a way to
> structure npm so that it can be expanded in the future without
> cluttering the API.
In addition to the above comments, I hope the system does not get too
heavily tied to git or github.
May I recommend that packages need not be loaded by require(), perhaps
you can just add a new function: requirePackage("ejs"). Then require()
and include() can be used specifically for loading files and not for
loading entire software. This will allow you more freedom.
I imagine it going like this:
ejs = requirePackage("ejs", "0.10.2+")
Even though I don't have the time right now to really look at this, I
think it's really great that you started it! We really need something
like this :)