Assets: publish to npm when a release is published

[dg]

The npm package only ever goes out by hand through workflow_dispatch, and then only as a 0.0.0-- snapshot under the master tag. Tagging a release publishes nothing, so npm latest still points at 7.1.0 from August while composer is at v7.2.0. Anyone taking the assets from npm is missing every fix since, the autosubmit ones among them - and the filter form now carries data-naja-unique from the template while the JS half of that fix is unavailable.

Publishing now also runs on a published release, taking the version from the tag and going out under latest.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 49.12%. Comparing base (ab5506d) to head (2234fb2).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1305   +/-   ##
=======================================
  Coverage   49.12%   49.12%           
=======================================
  Files          63       63           
  Lines        2974     2974           
=======================================
  Hits         1461     1461           
  Misses       1513     1513           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

This PR updates the GitHub Actions assets workflow so that the npm package is automatically published when a GitHub Release is published, using the release tag version and publishing under npm’s default latest tag (instead of only manual workflow_dispatch snapshot publishes under the master tag).

Changes:

• Add a release trigger (types: ["published"]) to the assets workflow.
• Introduce a publish-release job that sets the npm package version from the release tag and publishes to npm (default latest tag).

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[radimvaculik]

Thanks for this — the premise checks out. npm latest is still 7.1.0 (published 2025-08-04), v7.1.1 never made it to npm at all, and the v7.2.0 tag is from 2026-03-17. Meanwhile src/templates/datagrid.latte already emits data-naja-unique, so anyone pulling assets from npm gets the template half of that fix without the JS half. Automating this is overdue.

The mechanics look right to me: build has no if so it runs on the release event, checkout lands on the tag commit, ${GITHUB_REF_NAME#v} handles both v7.2.0 and 7.2.0, --allow-same-version covers a manually bumped package.json, and the existing workflow_dispatch guard on publish keeps the two jobs from double-publishing.

One thing I'd like changed before merging: if: github.event_name == 'release' also fires for pre-releases, and since no --tag is passed they'd go out as latest. The first v8.0.0-beta1 would then land on everyone installing without a pin, and undoing that means a manual npm dist-tag add after the fact.

My preference is to keep publishing them, just under a separate tag:

- run: npm publish --provenance --access public --tag ${{ github.event.release.prerelease && 'next' || 'latest' }}

That way betas stay installable via @next without touching latest. If you'd rather not publish pre-releases at all, the narrower guard works too:

if: github.event_name == 'release' && github.event.release.prerelease == false

Either is fine by me — happy to merge once one of them is in.