Live data from Hacker News

Show HN: ied – an alternative package manager for Node

github.com

71–80 of 89 posts

Re: Show HN: ied – an alternative package manager for Node

#71

Earlier quoted context omitted.

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.

Re: Show HN: ied – an alternative package manager for Node

#73
post #11

Earlier quoted context omitted.

> And, managing dependencies is like dealing with explosives anyways... Only funny for anyone who hasn't been affected by one, or had friends or family who were. Still better to avoid names with negative connotations (and search for them first to check). > Any suggestions are more than welcome! A few ideas: bpm - Better Package Manager edge - the thing that connects nodes jpm - Javascript Package Manager ppm - Peer P…

As I said earlier, it wasn't my intention to name it after a weapon. That being said, it's a three letter name. It's very unlikely NOT to run into naming conflicts here. edge - taken by Microsoft jpm - JPMorgan ppm - taken by Perl package manager: https://en.wikipedia.org/wiki/Perl_package_manager fpm - taken by Effing package management: https://github.com/jordansissel/fpm bpm - beats per minute ayp - terrible to ty…

I wouldn't worry about naming conflicts per se, just unfortunate or misleading ones (e.g. company names).

I think "bpm" is a clever name for a faster npm client because "beats per minute" is a speed measurement and thus associated with something going really fast.

IED on the other hand has the association of people dying or being crippled by terrorists.

Re: Show HN: ied – an alternative package manager for Node

#74
post #52

Earlier quoted context omitted.

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.

Re: Show HN: ied – an alternative package manager for Node

#75
post #46

Earlier quoted context omitted.

Delegating things to a library you give up control over any bugs the library has. You can't simply fix the bug like you would do to your code, you either need to fork the library (maintaining a fork has cost), patch it (maintaining the patch is not free), or send fixes to its maintainer -- or any combination of these. Using many dependencies also makes your application a fractal of dependencies. Library you use has i…

And writing custom code to duplicate a library doesn't have a cost? (compared to forking). I find that using tools like npm, nuget, gems, and the like along with github for core libraries makes managing dependencies FAR better than relying on an internal copy of said package in my project, which is just as risky as an internal fork. Yes, there's a chance the package system can be down while you are wanting to deploy.…

> And writing custom code to duplicate a library doesn't have a cost? (compared to forking).

Of course it does, but again: it's you who controls the code, not the library's upstream. You can easily patch and adjust whatever necessary, without being bothered with future merges from upstream.

This aspect grows in importance as the library gives less and less benefits. For example, I wouldn't hesitate to use Flask or Django for a web application, but I would think very hard what good is going to give me logging library other than Python's built-in.

> I find that using tools like npm, nuget, gems, and the like along with github for core libraries makes managing dependencies FAR better than relying on an internal copy of said package in my project

npm and gems give you dynamics very different from seeing dependencies by yourself. You see dependencies as very cheap (which is not true, it's just the cost is hidden from you), so you don't bother with thinking if you really need the new dependency. If it can shorten your code by twenty lines, you see it worth.

Re: Show HN: ied – an alternative package manager for Node

#76
post #3

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!

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?

Re: Show HN: ied – an alternative package manager for Node

#77
post #38
post #3

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!

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.

npm install --save

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

Re: Show HN: ied – an alternative package manager for Node

#78
post #49

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?

Its install process is very different from the one npm uses. E.g. just look into the node_modules directory produced by npm vs the one produced by ied. 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... :)

npm v3 already uses the 'flat by default' design, so the node_modules folders aren't that different.

Re: Show HN: ied – an alternative package manager for Node

#80
post #5

Earlier quoted context omitted.

I think it's fine as it is. Could have chosen a worse name for sure! And, managing dependencies is like dealing with explosives anyways...

> And, managing dependencies is like dealing with explosives anyways... Only funny for anyone who hasn't been affected by one, or had friends or family who were. Still better to avoid names with negative connotations (and search for them first to check). > Any suggestions are more than welcome! A few ideas: bpm - Better Package Manager edge - the thing that connects nodes jpm - Javascript Package Manager ppm - Peer P…

pkn - package node?

Super easy to type, and available on npm. https://www.npmjs.com/search?q=pkn

Post reply on HN