Downsides of distributing binaries via npm


#1

I’ve decided to use npm as means of distributing binaries for my github-agent little software. What do you think about this choice, how bad is it? Seems like not a bad option for little tools written in Haskell where you don’t want to spend too much time wrestling with snap/flatpak/deb/brew stuff.

I stole the scripts from the Elm project.


#2

A bit strange for non-js project, github release binaries would be for me enough.

Regarding binaries, Facebook does this all the time (thesee are mostly OCaml-Binaries, but js-related), with bucklescript/reason and flow.js. And they use Packagist (PHP registry) for Hacklang projects (but are working on their own package manager)…


#3

FWIW, a naming scheme akin to pandoc’s Releases might be more standardised.


#4

You mean the version, assets or something else? For version, 0.1.0.0 doesn’t work with npm. For assets, I agree, I’ve used one Elm has but would prefer something mentioning the program.


#5

Names like pandoc-2.8.1-linux-amd64.tar.gz or github-agent-1.1.0-linux-x86_64.gz are more common than binary-for-linux-64-bit.gz.


#6

I see. Agreed, will plan for the change in future.


#7

J. MacFarlane uses this naming scheme.

pandoc-2.8.1-linux-amd64.tar.gz
pandoc-2.8.1-macOS.pkg
pandoc-2.8.1-macOS.zip

Golang developers (presently) use this naming scheme.

go1.13.5.darwin-amd64.tar.gz
go1.13.5.darwin-amd64.pkg
go1.13.5.linux-amd64.tar.gz