Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

generate-fixtures: configurable asset store (local folder or Flysystem) with a content-hash manifest and pruning

Open
#462 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@silverbackdan is already working on this.

Since Oct 16, 2026.

  • #466 by @silverbackdan — open

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
10/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, php, symfony
Domain
backend

Research direction

Start with the generator behind generate-fixtures and the scaffold that loads files with new File(__DIR__ . '/assets/<name>'), then the bundle config under silverback_api_components.fixtures.assets. Pull request #466 is already open against this issue, so check its state before starting. Done means a settled design for the manifest, the store abstraction, and pruning, which needs maintainer agreement first.

Written by the indexing model from the issue text.

Description

generate-fixtures writes every stored file next to the scaffold (assets/), and the scaffold loads each one with new File(__DIR__ . '/assets/<name>'). For a real site that becomes a lot of binary in the repo.

Cymru Kitchens is the example: 710 images, 275 MB.

  • Committed: it more than doubles the git history permanently, and api/src is copied into the php image.
  • Excluded from the image: .dockerignore breaks a fixture load in a pod.
  • Git LFS: works, but it is a git-host choice the bundle shouldn't depend on.

The memory side of loading real-size snapshots is #460.

Proposal

1. The scaffold refers to files by content
  • The generator writes a manifest alongside the class, with one entry per file: sha256, size, mime type, original name, and the uploadable field it came from.
  • The class refers to a file by its hash, never a path.
  • Files are stored under content-hash names. An unchanged image keeps its name across regenerations, so diffs only show real changes, and a file used twice is stored once.
2. The location is bundle config, read by both generate and load
silverback_api_components:
  fixtures:
    assets:
      store: local                                   # local | flysystem
      path: '%kernel.project_dir%/fixtures/assets'   # local
      adapter: gcloud                                # flysystem: one of the app's adapters
      prefix: fixtures/                              # flysystem
  • generate-fixtures writes the files to the configured store and writes the manifest. doctrine:fixtures:load resolves each hash through the same store.
  • The class doesn't say where files live, so the same scaffold can load from a local folder for a developer and from a bucket in CI or a review app (store from an env var).
  • Command options override the config for one-off runs (--assets-store, --assets-dir).
  • Generating needs write access to the store, and loading needs read access. A Flysystem store reuses the app's existing adapters.
  • Default: a folder next to the scaffold, as today. Small sites and existing scaffolds keep working, and small sites can still just commit their assets.
3. Pruning follows the manifest
  • Local folder: generating rewrites the manifest and deletes any file in the folder it no longer references, so the folder always matches the class.
  • Flysystem: a command such as fixtures:prune-assets deletes objects under the prefix that no kept manifest references. "Kept" means the current manifest plus any listed (or recent) ones, so a branch still on an older snapshot can load. Hash names make this safe: an object is either referenced or it isn't.
  • Pruning git history is out of scope. Using a Flysystem store keeps large files out of history in the first place.
4. Optional size cap for development (--max-dimension)
  • Downscale images on export, e.g. to 2400 px, the widest variant, so nothing visible changes. This would cut a site like CK's assets a lot.
  • Off by default, because the default should stay byte-identical to production. The fixed-point check (generate, load, generate again: byte-identical) holds with it off.

Use on Cymru Kitchens

A Flysystem store pointed at a fixtures/ prefix in the existing media bucket, the manifest in git, and nothing large in the repo or the image. CK's snapshot is generated and verified, and it's waiting on this and #460.

Dominant language
PHP
Stars
32
Forks
8
Avg merge
40m
Merged PRs (30d)
133

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from components-web-app/api-components-bundle

All issues in components-web-app/api-components-bundle

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.