41–50 of 89 posts
I never thought to myself, "wow, npm is slow." Is that really the core problem this is solving?
Unfortunate naming ie https://en.wikipedia.org/wiki/Improvised_explosive_device
Damn. Didn't think of that. 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 ...'
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!
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 :)
You say you are creating a more performant NPM. Is it impossible to fix the current NPM? Why not submit fixes back to NPM? Why create a new project?
Earlier quoted context omitted.
This is why developers should try to avoid introducing dependencies. Not at all costs, of course, but typical project in JavaScript, Go, Ruby, or Python has way, way too many dependencies, while little of them have any significant benefit.
What's the downside? I think it's great. More modularity + distributed responsibility = better.
Using many dependencies also makes your application a fractal of dependencies. Library you use has its own dependencies, which have their own dependencies, which have... And so on. If you happen to want to put your application to DEB/RPM packages properly, host your app's dependencies locally to isolate from network outages, or do virtually anything non-trivial with your app, you hit the list of dependencies very hard.
It's not to say dependencies are evil; like any generalization, this would be simply stupid. But they have their cost, and it's large. You'd better make sure a library really simplifies your life before adding it to your project.
Earlier quoted context omitted.
Leave it as it is. It will be much easier to memorize.
Fully disagree. Really unfortunate/distasteful name - distracts from what I'm sure is a great project (see: conversation in this thread).
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!
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
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! :)
You say you are creating a more performant NPM. Is it impossible to fix the current NPM? Why not submit fixes back to NPM? Why create a new project?
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... :)
Earlier quoted context omitted.
Have you used any other package manager? I'm not completely sure if it's just Node's dependency hell, but npm feels so incredibly slow compared to Cargo or bundler or something.
Never profiled it but I would guess that is largely due to the npm's main problem: It doesn't locked dependency versions. As a result it probably builds the dependency graph a lot more than it should.