>We recently migrated our internal CLI tool from Node JS to Golang
Why? Out of things to do? Wanted to look productive?
We repurposed NPM to publish and distribute Go binaries for our internal CLI
61–65 of 65 posts
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#62I 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.
Or since it is an engineering CLI tool, why not have engineers: 1. clone cli repo 2. run goreleaser 3. copy binary to desired path sure, it's not 1 step (can be condensed with a build script), but it does teach the other engineers how to roll their own cli tool and contribute back if they fix a bug in it. Or if the blog indicated that not all engineers understand golang and build tools, and there's too many teams - t…
As the number of tools grow and the number of teams using/developing them grow this becomes more and more untenable. You not only have to maintain the tool itself, but also the build stacks associated with them and it becomes the task of the user to make sure they are running the most recent version. This leads to more complex support situations.
Basically, you need a deployment methodology that allows for: * Ease of use by "novice" developers * Only introduces minimal overhead for those developers * Makes it easy to upgrade or remove a tool you installed 6 months ago * Doesn't require a tool development team to come up with their own solution
This is a surprisingly tricky to do on a diverse environment with 1000+ internal users.
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#63I was very tempted to reuse a Maven repository for publishing the handful of small Python utilities we had. It's a standardised format, we already had the server set up, we already had different kinds of artifacts in there and multiple languages, and frankly Python-on-Maven dependency management can't be worse than what standard Python dependency management looks like.
I kinda do that today. We’re primarily a Java shop, but we’re using Python for FaaS. So we package up our code and dependencies into a zip and use Maven to push the resulting archive into our common repo.
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#64Earlier quoted context omitted.
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.
I've had far more problems with yarn, which sometimes decides it and it alone not longer has internet access and none of the "fixes" published over the years have worked. Instead, you have to just set your timeout really, really high. That's been the only fix for a good while, and it frequently does not work.
Older NPM could be a pain but modern NPM is pretty smooth and works just fine.
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#65Earlier quoted context omitted.
here's the summary: it opens with "We recently migrated our internal CLI tool from Node JS to Golang". It's just a way to keep using the hammer they already had, no matter if the problem is a nail or not. could be titled "how to hack your private npm server to be a OS package manager, because we don't want to learn our OS packaging"
Which raises the question: package management is just a bunch of nails; why do I need a specific hammer for each type of nail?
> why do I need a specific hammer
i call it "lazy opinionated adoption".
Why do you use apt in debian and yum on redhat?
Same reason as you write javascript for the browser. Just because someone put it there at some point. Would it be better to use python or anything else in the browser? sure! why don't you do it? because many people have done it before and there's no adoption!
package manager and languages are just like curl or wget. try one, command not found? try the other. meh. ...until you find people that assume other people can't learn. Then they will create a third option because other-people-are-dumb and it will be worse than both options you had before.