bun run lint:css hangs forever (lasertag check never returns) #2

Open
opened 2026-08-17 21:33:13 +00:00 by forgejo-admin · 0 comments

Symptom

bun run lint:css (lasertag check "src/**/*.module.css") never terminates. It prints the command echo and then produces no further output and no exit — observed running past 5 minutes with zero output on three separate invocations:

$ lasertag check "src/**/*.module.css"
   (nothing, forever)

It has to be killed manually. lasertag is pinned at ^0.5.2 (resolved 0.5.2) in the root devDependencies.

Why it matters

lint:css is one of only three quality gates this repo has (check, lint:css, and the module's tsc). A gate that never returns is a gate nobody can run, so CSS violations accumulate unseen. It is also not wired into .forgejo/workflows/release.yml, so nothing catches this in CI either.

Scope

Not a regression from the @celilo/capabilities@^2.0.0 bump (PR #1). That change touches only celilo-module/; lint:css reads src/**/*.module.css, which the bump does not modify, and the hang reproduces the same way independent of it.

Worth noting the invocation loses its quoting under zsh — the process shows as lasertag check src/**/*.module.css with the glob already expanded by the shell rather than passed through to lasertag. That may or may not be related to the hang, but it means lasertag is receiving a file list instead of the pattern it expects.

Suggested next steps

  1. Reproduce with a single file (bunx lasertag check src/<one>.module.css) to see whether it is the glob handling or the check itself.
  2. If the shell expansion is the trigger, the lint:css script needs the pattern protected from the shell.
  3. Once it returns reliably, add it to release.yml so it is actually enforced.

Filed while upgrading the celilo module (PR #1); the hang is pre-existing and outside that change's scope.

## Symptom `bun run lint:css` (`lasertag check "src/**/*.module.css"`) never terminates. It prints the command echo and then produces no further output and no exit — observed running past 5 minutes with zero output on three separate invocations: ``` $ lasertag check "src/**/*.module.css" (nothing, forever) ``` It has to be killed manually. `lasertag` is pinned at `^0.5.2` (resolved 0.5.2) in the root `devDependencies`. ## Why it matters `lint:css` is one of only three quality gates this repo has (`check`, `lint:css`, and the module's `tsc`). A gate that never returns is a gate nobody can run, so CSS violations accumulate unseen. It is also not wired into `.forgejo/workflows/release.yml`, so nothing catches this in CI either. ## Scope Not a regression from the `@celilo/capabilities@^2.0.0` bump (PR #1). That change touches only `celilo-module/`; `lint:css` reads `src/**/*.module.css`, which the bump does not modify, and the hang reproduces the same way independent of it. Worth noting the invocation loses its quoting under zsh — the process shows as `lasertag check src/**/*.module.css` with the glob already expanded by the shell rather than passed through to lasertag. That may or may not be related to the hang, but it means lasertag is receiving a file list instead of the pattern it expects. ## Suggested next steps 1. Reproduce with a single file (`bunx lasertag check src/<one>.module.css`) to see whether it is the glob handling or the check itself. 2. If the shell expansion is the trigger, the `lint:css` script needs the pattern protected from the shell. 3. Once it returns reliably, add it to `release.yml` so it is actually enforced. Filed while upgrading the celilo module (PR #1); the hang is pre-existing and outside that change's scope.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
celilo/homepage#2
No description provided.