bigskysoftware / bigskysoftware/htmx

`build:ext` does not clean `dist/ext`, so renamed extensions 404 (hx-optimistic at 4.0.0)

Open
#4,041 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
49.4k
Forks
1.7k
Avg merge
3d 22h
Merged PRs (30d)
30

Description

`build:ext` copies `src/ext/*.js` into `dist/ext` but never deletes the directory first. After a rename, the old basename stays in the published tarball (or an orphan `.map` does).

## Repro (4.0.0)

```
curl -I https://cdn.jsdelivr.net/npm/htmx.org@4.0.0/dist/ext/hx-optimistic.min.js
# 404

curl -I https://cdn.jsdelivr.net/npm/htmx.org@4.0.0/dist/ext/hx-pending.min.js
# 200
```

`hx-optimistic.js` was renamed to `hx-pending.js` in #3958. The 4.0.0 tree / npm pack still contains `dist/ext/hx-optimistic.min.js.map` with **no** matching `.js`. The same tree also still has a full leftover `hx-compat.*` set (`src/ext` only has `htmx-2-compat.js`).

Cause is mechanical: `package.json` `build:ext` is `mkdir -p dist/ext && for file in src/ext/*.js …` with no wipe. CI (`htmx 4 CI`) runs tests and `src/scripts/content/check.py`, but does not build dist or compare `src/ext` to `dist/ext`. `dev/RELEASE.md` also has no completeness check and no `--prerelease` for `-beta` / `-rc` tags (`v4.0.0-beta3` through `beta5` were published with `prerelease=false`; `beta6` was marked correctly).

## Ask

1. Wipe `dist/ext` at the start of `build:ext` so a release tarball is a pure function of `src/ext`.
2. Add a cheap completeness check (every `src/ext/*.js` has `.js` + `.min.js`; no dist basename that is not in src; every `.map` has a matching `.js`) and run it from CI after `bun run build`, and from the release checklist before `npm publish` / `gh release create`.
3. In `dev/RELEASE.md`: `npm publish --tag next` while 2.x remains npm `latest`; pass `--prerelease` on GitHub when the version contains `-`.

No runtime change. A changelog line on the next 4.x release that `hx-optimistic` is now `hx-pending` (old CDN path 404s) would help consumers. I am happy to send a `four-dev` PR for (1)–(3).

Not asking to move npm `latest` off 2.x — that policy is already documented.

Contributor guide

Open the contributing guide

Research direction

Start with package.json and the build:ext command, then inspect the CI path that runs bun run build and src/scripts/content/check.py. Review dev/RELEASE.md for the publishing and prerelease checklist. Done means stale dist/ext files are excluded, completeness is checked in CI and release preparation, and the documented npm and GitHub release commands match the stated policy.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
build-system, ci-cd, documentation, release
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
64/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.