Publish wasm API to npm

[mattrunyon]

Summary

Will need to add an actions secret NPM_TOKEN that is an npm token w/ publish rights to the @astral-sh org. It seems right now the "best" option for is a classic automation token which never expires (npm scoped tokens expire which would cause this to randomly fail after it expires).

Fixes #1385

Added ruff_wasm to the pyproject version_files.

Added a build and publish wasm job with cargo-dist. I am not familiar with this toolchain, but I regenerated the publish action. Note this does not add the wasm build to the GH release artifacts.

This will publish @astral-sh/ruff-wasm-{target} where target is web, bundler, or nodejs

Test Plan

I test published this in my fork with a few modifications

• workflow_dispatch for the build/publish action so it could be run standalone
• Published under my npm scope
• Changed repo URL to my fork so npm provenance works
• Bumped the version for the 2nd successful publish to check the LICENSE file copied properly

Workflows: https://github.com/mattrunyon/ruff/actions/workflows/publish-wasm.yml
npm: https://www.npmjs.com/package/@mattrunyon/ruff-api

[MichaReiser]

Wow this is neat.

I prefer to keep the old ruff_wasm crate name. ruff_api feels to generic as a crate name.

I see that this package now only publishes the web bindings. I wonder if we need multiple packages similar to what BiomeJS does (they actually have an even more complicated setup) where they have a web, node (possibly deno) and bundler package.

[mattrunyon]

I've updated the warning and also adjusted the naming w/ a CI matrix job to publish 3 wasm-pack targets. I haven't used deno, but looks like it doesn't use package.json so it would need its own slightly different job probably

Test run on my fork here: https://github.com/mattrunyon/ruff/actions/runs/9935706011
Example should be published in a few minutes to https://www.npmjs.com/package/@mattrunyon/ruff-wasm-web

[MichaReiser]

Nice thank you. We now need @charliermarsh to add the NPM token.

[charliermarsh]

Thanks for the ping -- I'll get to this today.

[charliermarsh]

@MichaReiser -- I added NPM_TOKEN to the repo with read/write access on @astral-sh.

[MichaReiser]

We need to add the Cargo.toml to

ruff/pyproject.toml

Lines 105 to 112 in 7a7c601

	version_files = [
	"README.md",
	"docs/integrations.md",
	"crates/ruff/Cargo.toml",
	"crates/ruff_linter/Cargo.toml",
	"scripts/benchmarks/pyproject.toml",
	]

or it won't get automatically updated when doing the next release.

[MichaReiser]

Thanks @charliermarsh . Stupid question. How can I dry-run the workflow? And is the trigger for the npm workflow in the correct release step?

[mattrunyon]

I saw something about a tag=dry-run in some other workflows. If that actually runs the publish jobs, then could add a check to instead run npm publish --dry-run if that's the case. It will just print out what would have happened, but doesn't actually check the validity of the token (it will warn if there was no token)

[mattrunyon]

Nevermind, looks like dry-run probably doesn't publish based on this line in publish.yml

publishing: ${{ inputs.tag && inputs.tag != 'dry-run' }}

[MichaReiser]

Hmm okay. Let's see if @charliermarsh has an idea on how to test it or we'll test on release day 😆

[mattrunyon]

If anybody w/ more knowledge on the release system wants to adjust this in the future to separate build and publish, you would basically run everything except the setup-node and publish steps and upload the resulting crates/ruff_wasm/pkg to an artifact. Then download the artifacts, run setup-node and then npm publish for each.

Could also run setup-node in both build and publish and then run npm pack crates/ruff_wasm/pkg --pack-destination some_optional_dir_if_not_current_dir to create a tarball. Then upload the resulting <name>-<version>.tgz. Then npm publish <name>-<version.tgz those

[MichaReiser]

Most our workflows use taiki-e/install-action for fast installation of cargo dependencies

[mattrunyon]

I stole this setup from the playground workflow, so might want to update both at some point

[charliermarsh]

@MichaReiser - You should be able to release with dry-run as the tag (it should be the pre-populated default).

The check in GitHub Actions is ${{ inputs.plan != '' && !fromJson(inputs.plan).announcement_tag_is_implicit }}. You can see an example in build-docker.yml.

[mattrunyon]

There is currently nothing handling dry-run in the action and build/publish are in the same workflow. So fair warning if the action runs at all it will try to publish. I mostly wasn't sure about how the different release steps worked w/ dry-run and I thought the publish jobs were skipped entirely w/ dry-run

[charliermarsh]

@mattrunyon - I will check...

[charliermarsh]

Confirmed that publish jobs do not run with dry-run.

[charliermarsh]

I think I would make just make the new job workflow_dispatch too and then skip the publish step if ${{ inputs.plan == '' || fromJson(inputs.plan).announcement_tag_is_implicit }}, so we can test the rest manually without publishing.

[charliermarsh]

LGTM! I’ll let @MichaReiser merge.

[mattrunyon]

Here's a run from my fork: https://github.com/mattrunyon/ruff/actions/runs/9963353823

If there's no token, the 2nd or 3rd to last line of the dry-run publish output will say something like "warning: You need to login to npm"

Due to how Github actions work, there's no way to dry-run this until it merges (since there's no workflow w/ the same name already on main)

[MichaReiser]

Thanks again @mattrunyon for this amazing contribution. The dry run was completed successfully.

https://github.com/astral-sh/ruff/actions/runs/9969546556/job/27546697354

[MichaReiser]

Yes, the packages should be published once we do the next release.