Live data from Hacker News

We repurposed NPM to publish and distribute Go binaries for our internal CLI

medium.com

41–50 of 65 posts

Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI

#41
post #30

Earlier quoted context omitted.

When you have one thing to nail and already own a hammer, why go and buy another one? Even if it's not a good one, it's gonna do the job, and be the least trouble.

The choice of package manage is much stickier than the choice of hammer. I can trivially change hammers between projects or even between nails. Changing package managers is a lot more involved, and gets more involved as it's used more---and they've just established a precedent for using npm to package go binaries.

Meh, depends. For their case, for an internal CLI tool that will get used interactively on development environments, it's fine, the cost of switching is not very heavy. At worst they're postponing the work of deploying on other package managers, and devs will have to run 2-3 commands to remove the npm package, configure whatever next place it gets deployed to and install the new executable.

Not a big deal at all.

Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI

#42
post #22

This just saddens me deeply. Of all the ways this could have been done and all the package managers they could have used they picked npm. I bet some day we'll have a Linux distro with npm as the system package manager here on HN.

It saddens you that someone used a tool they already use instead of adding another thing to distribute a small binary?

deeply

Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI

#43

I wish commentors would read the article. Why didn't they use the os package manager? Which OS? Their build clearly builds for osx, windows, and Linux.

NPM could handle different OS, I would guess they run more than 1 os. (It is also a tool which the team is used to handle, as they have been using node + npm)

Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI

#44
post #36

Earlier quoted context omitted.

The choice of package manage is much stickier than the choice of hammer. I can trivially change hammers between projects or even between nails. Changing package managers is a lot more involved, and gets more involved as it's used more---and they've just established a precedent for using npm to package go binaries.

They established the choice of npm when they choose to be a JS shop, that's exactly their argument.

Sorry I wasn't clear, I'm not making an argument for or against npm, only responding to the analogy.

But I wouldn't consider "we're already using X" to be sufficient reason to use X for something it wasn't designed around. Again, these choices are sticky and tend to be vulnerable to scope creep. I'd call it a textbook case of technical debt, and it's ok to point that out. They might have forestalled the criticism by acknowledging that, but they didn't.

Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI

#45
post #41

Earlier quoted context omitted.

The choice of package manage is much stickier than the choice of hammer. I can trivially change hammers between projects or even between nails. Changing package managers is a lot more involved, and gets more involved as it's used more---and they've just established a precedent for using npm to package go binaries.

Meh, depends. For their case, for an internal CLI tool that will get used interactively on development environments, it's fine, the cost of switching is not very heavy. At worst they're postponing the work of deploying on other package managers, and devs will have to run 2-3 commands to remove the npm package, configure whatever next place it gets deployed to and install the new executable. Not a big deal at all.

Sure, should have s/much stickier/sticker/. I'm not going to comment on whether the tradeoffs are worth it, I just thought the hammer analogy doesn't work due to material differences in how you switch between hammers vs package managers.

Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI

#47
post #6

I need a medium account to read this for some reason.

> "This is your last free member-only story this month. Sign up for Medium and get an extra one" Well, that's about the end of medium I think.

Not logging in gives you a better experience than being logged in, especially when you can use incognito mode.

Only website that punishes being logged in.

Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI

#48
post #46

Go supports native packages natively via go get, why the hell bring npm into the picture?!?

> As the project completed we ran into the issue of distributing the CLI tool to our team of engineers without the need of distributing a new set of tokens or making the binary public.

From the article itself, it seems like they wanted to re-use their existing process without disruptions.

Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI

#50
post #22

Earlier quoted context omitted.

It saddens you that someone used a tool they already use instead of adding another thing to distribute a small binary?

I guess my comment appears rude, which wasn't intended, I just find npm a troublesome piece of software that is passable as a package manager for the javascript ecosystem, but not a tool one solves problems with if there are viable alternatives.

I don't know why but I never encountered issues using npm.
Post reply on HN