alunduil / alunduil/projects-v2-sync

A stale dist/ cannot reach main

Aperta
#10 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub
enhancement
Lingua principale
TypeScript
Stelle
0
Fork
0
Merge medio
53m
PR unite (30g)
1

Descrizione

## Summary

The bundle-freshness check is the only thing standing between a stale
`dist/` and consumers, and nothing requires it to pass. Make it block, and
close the gap it cannot see.

## Motivation

#1 settled the approach: `dist/` stays committed and CI verifies it, the
way `actions/typescript-action` does. That makes the `Bundle is current`
job load-bearing. Today it is advisory:

```console
$ gh api repos/alunduil/projects-v2-sync/branches/main/protection
Branch not protected (HTTP 404)
```

No required status checks, so a red run does not stop a merge.

There is a second gap that protection alone does not close. The repository
is squash-merge only, so each pull request lands as one commit built from
*its* base. Two pull requests branch from `main@X`, both edit `src/`, both
commit a correct bundle. A lands; B lands; `main` now ships a bundle built
from `X + B` that is missing A entirely — with both having been green.

GitHub narrows this but does not close it. `pull_request` runs check out
`refs/pull/N/merge`, so the bundle job already rebuilds against the merged
tree rather than the branch in isolation. What it does not do is re-run
checks when the base advances, so a run that went green before A landed
stays green afterwards. **Require branches to be up to date before
merging** is what forces the re-run, and it is a settings change rather
than new CI.

Separately, the check only ever reports the mistake. A pre-commit hook
that rebuilds when the sources change would make the bundle correct rather
than merely checked, leaving CI as the backstop for anyone who used
`--no-verify`.

## Scope

- Protect `main`: require the `Lint, typecheck, and test`, `Bundle is
current`, and `Action loads and exits clean` checks, and require
branches to be up to date before merging.
- Add a local pre-commit hook running `pnpm run build` when `src/`,
`scripts/build.ts`, `package.json`, or `pnpm-lock.yaml` changes. It
will fail the commit with "files were modified by this hook" until the
rebuilt bundle is staged, which is the same flow the prettier hook
already uses here.
- Decide whether the up-to-date requirement is wanted permanently. It
costs a rebase per pull request whenever two are open at once, which is
cheap for a single maintainer and less so later.

## Acceptance criteria

- [ ] A pull request with a stale bundle cannot be merged.
- [ ] A pull request whose bundle went stale because the base advanced
cannot be merged without a re-run.
- [ ] Editing a source file and committing without rebuilding fails
locally, not only in CI.
- [ ] `main` stays green across two pull requests that touch `src/`
concurrently.

## Additional context

- Raised while deciding whether a branching strategy would give better
control over what is published. It would not: the useful axis is who may
write `dist/`, not which branch it sits on. Keeping it in-tree is the
choice made, so the guards have to be real.
- Revisit at #4. If the release workflow becomes the only writer of the
bundle, the freshness check stops being necessary by construction, and
most of this issue is superseded.

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.