Hacker News new | ask | show | jobs
by blubbi2 3867 days ago
Hey everyone!

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!

5 comments

Is your plan to remain compatible with `npm` projects?

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 :)

Although using ied and npm at the same time for installing dependencies should work, you might run into some weird corner cases.

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 :)

Good to hear, I reckon I could quite happily use ied for all the installing stuff if it's going to produce the same tree as npm, but perhaps not support all of the crazy corner cases.
For the discovery and installation, you might be interested in looking into using IPFS for it. Kind of gives you all the features you want out-of-the-box. Also, another guy is working on mirroring the npm registry in IPFS, might be interesting for you: https://github.com/diasdavid/registry-mirror
Hi Alexander, this is really great!

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! :)

This looks very interesting!

Also related: https://github.com/dominictarr/npmd

if you can make this work in a way that it's capable of reinstalling a precise snapshot (like using a Gemfile.lock in Ruby's Bundler world) and keep it stable then I once again will have faith in JS package management.
You know npm shrinkwrap does exactly this, right?
Does it support installing packages globally and then having them actually be available, without having to install them locally as well?

This is my biggest bugbear with npm, as it pretty much rules out doing shell scripting with node.

If you keep node in ~/bin/, you could symlink your global npm path to ~/bin/node_modules/ .. just a thought here.
I mean if you keep your shell scripts in ~/bin/ (which is where I happen to keep mine)... I use straight bash scripts most of the time, but it's usually easiest for me to use node/js since my environment already has it than it is for me to try to remember perl, learn python or use something else.
Making using a shrinkwrap not awful would be amazing.

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.

Great to hear that! shrinkwraps + rollbacks are definitely coming!
npm install --save

In npm v3 updates the shrinkwrap as well as the package.json