I made this. I'm happy to answer any questions, but please bear in mind that this is a WIP. There is still a lot of work to be done, although feature parity with npm is not the goal.
Upcoming features are:
* Nix-like rollbacks * built in registry server * discovery + installation via BitTorrent DHT
Would love to get any feedback!
I could see a case where I'd use `ied` to install deps for the speed, but continued to use npm for other features and interop with others.
This could be very useful - but would need shrinkwrap support along with the stuff on your TODO to make it viable for my current work projects :)
Therefore, npm and ied are compatible in the sense that you can use ied to install packages and npm for publishing them. At least that's the level of compatibility that is currently supported.
shrinkwrap is definitely coming :)
I've started `registry-mirror` to demonstrate how a Content-Addressed file structure and P2P discovery, can bring a lot of speed improvements, specially when the bottleneck is low bandwidth/latency to the backbone, by connecting to more local peers that have the content that we are looking for.
Right now, the goal with `registry-mirror` is to have a very large IPFS node in the network with the entire npm and that keeps replicating it, while end user machines only download the modules they need (and if they agree, provide them to the network as well). Each end user will be able to get the latest state of the registry, through a IPNS hash, a mutable pointer, that changes each time the mirror is updated.
The nix package manager model layers perfectly on top of IPFS' MerkleDAG (https://github.com/ipfs/specs/tree/master/merkledag), it can be a very awesome transport for ied. An example of a package manager that uses IPFS to distribute the packages is GX https://github.com/whyrusleeping/gx - Still a WIP.
If this is interesting to you, join us at IRC Freenode #IPFS, it would be great to bounce more ideas! :)
Also related: https://github.com/dominictarr/npmd
This is my biggest bugbear with npm, as it pretty much rules out doing shell scripting with node.
Having fast immutable shrinkwrap installs, and the ability to upgrade or selectively upgrade packages in the shrinkwrap vs. the semver in package.json would be a huge win.
`ied publish` and `ied version` is coming next week. I'm also thinking of adding scoped modules, but I'm not sure about that yet.
You can also configure a private npm registry to be used: https://github.com/alexanderGugel/ied/blob/master/lib/config...
npm install 52.28s user 8.08s system 73% cpu 1:22.41 total
ied install 10.22s user 4.36s system 142% cpu 10.230 total
Very promising project!
In answer, why not create a new project? NPM INC controls npm, hasn't contributed it to the node foundation (despite playing a pivotal role in creating said foundation), and hasn't been especially good at taking contributions recently.
A new project dodges all those existing problems, demonstrates alternate approaches are both feasible and compatible, and destroys the myth that npm is fundamental to node, rather than simply the first of many package management systems that take advantage of node's import semantics.
Also the way it wires up dependencies (using symlinks) has been called "non humane design" by npm... so I thought it would be easier to just start a new project... it's not a lot of code/logic needed there actually... :)
Part of that is just the monstrous number of files involved. For example, one of our projects has 48 dependencies, which installs 24,421 files under node_modules. NPM could probably benefit from managing each dependency as an archive.
We do atomic deploys and try to make them reproducible, so for each deploy we do a fresh install from npm-shrinkwrap.json, but even when all the modules are in NPM's local cache it's very slow at copying everything.
Unfortunately, NPM doesn't version the node_modules folder (a package becomes ./node_modules/mypackage/...)), so you can't reuse it. The NPM cache is versioned ($cachedir/mypackage/3.23/...), but can't be used directly. It would be much better to skip the cache altogether, and have node_modules embed version strings (./node_modules/mypackage-3.23/...). Then you could easily share the folder across builds.
NPM is also pretty brittle. We frequently have deploys fail because of transient network errors (repository timing out or similar) that cause NPM to fall over. The dreaded mysterious "npm ERR cb() never called" error still hits us weekly.
(Speaking of reproducible builds: NPM lets people unpublish packages. Sometimes old versions just disappear, presumably because they were unpublished. 6 months later you want to deploy a certain app, and you find it depends on some package X, which deep in its dependency graph relies on package Y 0.3, but 0.3 is gone from npmjs.com, so you have to upgrade for no reason at all.)
Bootstrapping ftw.
This is a "cool" feature during development, since it's a nice proof of concept.
Originally I checked in the node_modules directory, but then reddit was shitting on me as usual (yes, you shouldn't check in node_modules in an actual app, but this is PACKAGE MANAGER!). As far as I know, npm has also its own dependencies check in + a ton of packages as tarballs for tests, so I might do that later.
Finally. npm's node_modules makes Node on Windows unbearable from time to time.
Shut up and take my money!
In fact I literally just renamed it: https://github.com/alexanderGugel/ied/commit/84628b3c871c85d...
Originally it was called mpm, but I figured that would have been pretty confusing, but it looks like the new name isn't necessarily better.
I'm pretty terrible at naming. Any suggestions are more than welcome!
'$ package install ...'