wintercms / wintercms/winter

Commit a lockfile (package-lock.json) for reproducible Mix asset builds

Open
#1,492 0 comments 0 reactions 0 assignees View on GitHub

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 ci rather than npm install for 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
  • sortablejs was 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

Open the contributing guide

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.

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.