Best practices: excessive to fix (optional) #15

New Issue

2026-09-15T09:22:35-04:00

lyra commented

2026-09-15 09:22:35 -04:00

Excessive / Optional

These are fine to leave alone; only worth touching if the mood strikes.

1. bin/composer (3.2 MB binary) is committed. It's a vendored copy of the Composer PHAR. CI (setup-php + composer/install) and the Dockerfile (COPY --from=composer) never use it, and composer.phar is already in .dockerignore. It's harmless but bloats every clone and the build context. Keeping a bootstrapped composer in-repo is a legitimate choice, so this is "excessive to fix," but removing it (or moving to a documented download step) is the cleaner pattern.
2. No .gitattributes with export-ignore. Standard for libraries/apps that get distributed: mark tests/, docs/, .gitea/, CI configs, .php-cs-fixer.dist.php, etc. export-ignore so git archive/dist zips are clean. Since this repo is primarily built from a Dockerfile (not git archive), this is optional.
3. No .editorconfig enforcement in CI. The file exists but nothing checks it. Not worth wiring up unless the team wants it.
4. No explicit failOnRisky/beStrictAboutOutputDuringTests in phpunit.xml.dist. The config already fails on deprecations/notices/warnings; adding riskiness strictness is a further tightening that could be noisy. Current strictness level is reasonable.
5. Caddyfile / bin/franken.sh / bin/dev.sh are dev conveniences shipped in the repo. Fine to keep; a full monorepo-cleanup (moving dev scripts under a tools/ dir) is cosmetic.
6. composer.lock hash not pinned in CI. CI relies on composer install (which is correct). Adding a --strict or a lock-freshness check is overkill for a single-maintainer app.

## Excessive / Optional These are fine to leave alone; only worth touching if the mood strikes. - [ ] **1. `bin/composer` (3.2 MB binary) is committed.** It's a vendored copy of the Composer PHAR. CI (`setup-php` + `composer/install`) and the Dockerfile (`COPY --from=composer`) never use it, and `composer.phar` is already in `.dockerignore`. It's harmless but bloats every clone and the build context. Keeping a bootstrapped composer in-repo is a legitimate choice, so this is "excessive to fix," but removing it (or moving to a documented download step) is the cleaner pattern. - [ ] **2. No `.gitattributes` with `export-ignore`.** Standard for libraries/apps that get distributed: mark `tests/`, `docs/`, `.gitea/`, CI configs, `.php-cs-fixer.dist.php`, etc. `export-ignore` so `git archive`/dist zips are clean. Since this repo is primarily built from a Dockerfile (not `git archive`), this is optional. - [ ] **3. No `.editorconfig` enforcement in CI.** The file exists but nothing checks it. Not worth wiring up unless the team wants it. - [ ] **4. No explicit `failOnRisky`/`beStrictAboutOutputDuringTests` in phpunit.xml.dist.** The config already fails on deprecations/notices/warnings; adding riskiness strictness is a further tightening that could be noisy. Current strictness level is reasonable. - [ ] **5. `Caddyfile` / `bin/franken.sh` / `bin/dev.sh` are dev conveniences shipped in the repo.** Fine to keep; a full monorepo-cleanup (moving dev scripts under a `tools/` dir) is cosmetic. - [ ] **6. `composer.lock` hash not pinned in CI.** CI relies on `composer install` (which is correct). Adding a `--strict` or a lock-freshness check is overkill for a single-maintainer app.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: public/preauth#15