Commit a lockfile (package-lock.json) for reproducible Mix asset builds
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 1.5k
- Forks
- 246
- Avg merge
- 19h 2m
- Merged PRs (30d)
- 7
Description
Problem
The backend module (and other Mix packages) declare their npm dependencies with caret ranges (^) in package.json, and there is no committed lockfile (package-lock.json). As a result, php artisan mix:install / npm install resolves each dependency to the newest version within its range, which drifts over time away from the versions the committed compiled assets (modules/backend/assets/ui/js/build/vendor.js, modules/backend/formwidgets/*/assets/js/dist/*.js, etc.) were originally built with.
When anyone subsequently runs php artisan mix:compile, the regenerated assets differ from what's committed — not because of any source change, but purely due to dependency version drift. This produces noisy, unrelated diffs in the compiled bundles and makes asset builds non-reproducible.
Concrete example (surfaced in #1491)
While adding a SortableJS bundle in #1491, running mix:compile -p module-backend regenerated vendor.js, colorpicker.js, and iconpicker.js with no source changes, purely because the local install had drifted:
| Dependency | Range | Committed assets built with | Locally resolved |
|---|---|---|---|
vue |
^3.2.45 |
3.5.18 (embedded in vendor.js) |
3.5.28 |
@simonwep/pickr |
^1.8.2 |
unknown (not embedded) | 1.9.1 |
constrained-editor-plugin |
^1.3.0 |
unknown (not embedded) | 1.4.0 |
Only vue's build version is recoverable (it's embedded in vendor.js); the others aren't, so the canonical versions can't be reconstructed after the fact — which is exactly why a lockfile is needed.
Proposed fix
- Commit a
package-lock.json(at the npm-workspaces root) generated in the canonical build environment. - Use
npm cirather thannpm installfor CI / asset compilation so installs are deterministic. - Optionally rebuild & commit the affected bundles once so the lockfile and committed assets are in sync going forward.
Notes
sortablejswas pinned to an exact version in #1491 as a stopgap for the dependency that PR introduced, but that does not address the pre-existing drift of the other dependencies.- This is a repo-wide build-reproducibility concern, intentionally kept out of #1491 to keep that PR focused.
🤖 Generated with Claude Code
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the npm-workspaces root and inspect the package.json files, the existing asset build commands, and the committed bundles under modules/backend/assets/ui/js/build/ and modules/backend/formwidgets/*/assets/js/dist/. Generate the canonical package-lock.json, update CI or asset compilation to use npm ci, and verify whether the affected bundles need rebuilding so installs and committed assets remain reproducible.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js, php
- Domain
- build-system, ci-cd
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100