NPM distribution for use in JavaScript projects?

[TheSpyder]

[edit: see #561]

I was wondering if you'd consider adding an NPM distribution of changie to aid using it in JavaScript projects.

The JavaScript ecosystem, for better or worse, doesn't like installing system-level tools; even binary tooling goes into node_modules and is then executed locally within the project.

For an example of a tool written in go that offers a NPM distribution, look at esbuild:
https://www.npmjs.com/package/esbuild
https://github.com/evanw/esbuild
https://github.com/evanw/esbuild/tree/main/npm/esbuild
https://github.com/evanw/esbuild/tree/main/npm/%40esbuild

[miniscruff]

If there was a super easy and automatic way of wrapping a binary in JS maybe, but it would have to be entirely unrelated to the core changie work. I would not want to have to update the JS code/tooling whenever I work on a feature or bugfix. I would say the same is true for any other language distributions like python or whatever.

[TheSpyder]

Absolutely. The JS involved doesn't wrap the binary, it just moves the correct platform binary into a predictable location for NPM to link to. This JS doesn't change for each release, it's written once and then it's done.

There are two ways to run an npm binary distribution:

• ship all platform binaries in one NPM package (much easier for small tools)
• set up what esbuild has done, a new package for each platform and rely on NPM's peer dependency conditions to only download the correct one.

If you're open to this, I or my team should be able to spare some time to help set it up.

[miniscruff]

Hmm, I am willing to do the work of setting up npm for publishing, if you are able to setup any of the js things and update the release pipeline for it.

For example using changies replacement feature to update any version string and the GitHub release workflow.

Will need to add it as an install option in the docs as well.

I might have some extra requirements but it has been a very long time sense I published to npm so I can't remember them right now.

[TheSpyder]

I'm not familiar with go release tooling but I'm happy to help any way I can!

I did a bit of a detailed writeup on how one of my projects achieves binary NPM distribution, but then after some quick research I found articles specifically describing how to distribute go binaries on NPM 😂

https://github.com/sanathkr/go-npm
https://blog.xendit.engineer/how-we-repurposed-npm-to-publish-and-distribute-our-go-binaries-for-internal-cli-23981b80911b

The first downloads the appropriate binary at install time, which is certainly easy but not ideal for anyone using changie in multiple projects (which I will be). The second takes go-npm and reworks it to use multiple binaries published in a single NPM package, while a little wasteful on size I think this is the best option for now.

The sample JavaScript file in the article is overkill for what it does but I can shrink that down when I contribute it. The key to the whole thing is publishing an NPM package with every supported binary in a folder and the JavaScript, set up as a postinstall, copies the appropriate binary into a stable location defined by a bin config reference.

For example using changies replacement feature to update any version string and the GitHub release workflow.

Yes it should be quite simple to use replacement to update the version string in package.json.

Will need to add it as an install option in the docs as well.

Once this is all set up, the process for using changie via NPM will be

• install npm i -D changie
• run npx changie

Although technically npx changie will also work without installing first.

[miniscruff]

I think that all sounds good, I am curious how you are going to get the binaries for the installer, maybe a goreleaser hook or something? But whatever you need to do should be fine with me, let me know if I can help but I don't know much about this stuff either.

[TheSpyder]

In my project, which uses a matrix github actions to build because OCaml doesn't have easy cross-compilation, it grabs the binaries from the delegate action runners directly 😂
https://github.com/TheSpyder/bs-atdgen-generator/blob/b1d421004b8161642ae482e622eee8db3caaba8f/.github/workflows/main.yml#L134-L153

Strangely, although your release action claims to mark the executables as artifacts, they don't show up under the summary artifacts list.

Maybe I can just build something into the existing release workflow instead of making it a new workflow. That sounds harder to test, although the process is very well established.

[miniscruff]

You can use goreleaser locally to generate the builds in the dist folder, I think it's like --dry or --skip-publish