What
.dockerignore excludes composer.lock, package-lock.json, and yarn.lock from the files sent to the Docker build context (under the "Dependencies" section). But Dockerfile runs composer install --no-dev --optimize-autoloader --no-interaction (in the php-base/production stages), which is meant to install exact, tested dependency versions from its lockfile.
Where
.dockerignore (composer.lock, package-lock.json, yarn.lock entries)
Dockerfile (RUN composer install ...)
Update (2026-09-05): commit 0d80cbd (#209, "build frontend assets in the Docker production image") added a second, unlocked install to the Docker build: a new node-build stage that runs npm install && npm run build (line 68) — not npm ci — to produce public/build, which was previously missing entirely from the production image. That commit only removed vite.config.js from .dockerignore (needed for the build to run at all); package-lock.json remains excluded, so this new npm install is just as unlocked as the pre-existing composer install. The original reproducibility gap is unchanged, and the scope of this issue is now slightly wider: both installs (Composer and npm) run without their lockfiles in the build context.
Why it matters
Without composer.lock/package-lock.json present in the build context, Composer/npm have no lockfile to install from and resolve dependency versions fresh against version constraints at build time. That means every image build can pull different (and untested) dependency versions rather than the exact versions committed and presumably tested in CI/locally — defeating the entire purpose of a lockfile and risking supply-chain drift between what's tested and what's deployed.
Suggested fix
Remove composer.lock and package-lock.json from .dockerignore so they're copied into the build context, and use them in lockfile-respecting mode: composer install (already does, once the lockfile is present) and switch the node-build stage's npm install to npm ci (line 68 of Dockerfile), which requires and honors package-lock.json.
What
.dockerignoreexcludescomposer.lock,package-lock.json, andyarn.lockfrom the files sent to the Docker build context (under the "Dependencies" section). ButDockerfilerunscomposer install --no-dev --optimize-autoloader --no-interaction(in thephp-base/productionstages), which is meant to install exact, tested dependency versions from its lockfile.Where
.dockerignore(composer.lock,package-lock.json,yarn.lockentries)Dockerfile(RUN composer install ...)Update (2026-09-05): commit
0d80cbd(#209, "build frontend assets in the Docker production image") added a second, unlocked install to the Docker build: a newnode-buildstage that runsnpm install && npm run build(line 68) — notnpm ci— to producepublic/build, which was previously missing entirely from the production image. That commit only removedvite.config.jsfrom.dockerignore(needed for the build to run at all);package-lock.jsonremains excluded, so this new npm install is just as unlocked as the pre-existingcomposer install. The original reproducibility gap is unchanged, and the scope of this issue is now slightly wider: both installs (Composer and npm) run without their lockfiles in the build context.Why it matters
Without
composer.lock/package-lock.jsonpresent in the build context, Composer/npm have no lockfile to install from and resolve dependency versions fresh against version constraints at build time. That means every image build can pull different (and untested) dependency versions rather than the exact versions committed and presumably tested in CI/locally — defeating the entire purpose of a lockfile and risking supply-chain drift between what's tested and what's deployed.Suggested fix
Remove
composer.lockandpackage-lock.jsonfrom.dockerignoreso they're copied into the build context, and use them in lockfile-respecting mode:composer install(already does, once the lockfile is present) and switch thenode-buildstage'snpm installtonpm ci(line 68 ofDockerfile), which requires and honorspackage-lock.json.