We repurposed NPM to publish and distribute Go binaries for our internal CLI
1–10 of 65 posts
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#2Given NPM registries are presumably optimized to store text, I wonder how this scales and if other repositories that do expect binaries (eg. Maven, NuGet) compare.
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#3What, did curl not work?
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#4Given NPM registries are presumably optimized to store text, I wonder how this scales and if other repositories that do expect binaries (eg. Maven, NuGet) compare.
NPM packages are uploaded / stored as `.tar.gz` files, so they can contain anything (alongside a package.json metadata file) - some public NPM packages contain binary files like images or compiled assets too. The registry doesn't really care about much beyond the package.json.
I've done something similar to the author at a previous company, distributing an internal development CLI written in Go, though in our case we published to the GitHub Packages NPM registry rather than private npmjs.com, so we could authenticate our developers via their GitHub accounts.
Including multiple binaries inside the published package, one for macOS and one for Linux (we had no Windows devs), did increase the package size, but the whole gzipped .tar.gz was around 20-30mb, so not terrible from a registry storage standpoint.
Publishing to an NPM registry, vs just hosting a binary for our devs to download, was convenient since we could use the registry API to check for updates and notify the user that an update was available. Users could then update via a subcommand, which just pulled the new package from the registry.
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#5What, did curl not work?
I haven't read the article yet, but I would assume they want versioning, history, checksumming and verification. All that stuff is worthwhile, it's just unfortunate npm is such a heavy dependency to achieve it.
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#6I need a medium account to read this for some reason.
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#7What, did curl not work?
I haven't read the article yet, but I would assume they want versioning, history, checksumming and verification. All that stuff is worthwhile, it's just unfortunate npm is such a heavy dependency to achieve it.
Not that heavy if they're already using it though
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#8What, did curl not work?
"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"
Seems a neat enough hack to make their newer shit available internally using existing tools/security.
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#9I 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.
Re: We repurposed NPM to publish and distribute Go binaries for our internal CLI
#10I need a medium account to read this for some reason.
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"