mirror of
https://github.com/dsh-market/dsh-market.git
synced 2026-09-28 05:03:07 +08:00
fkysly
9bdfd06f89
* fix: drop the stale pnpm lockfile, and prove the bundle rebuilds in CI #472 by @Tony-ooo, two staleness reports, both verified. The pnpm-lock.yaml was real but abandoned: last touched around #124, it predates seven of the current dependencies (it does not mention dsh-settings at all), so `pnpm install --frozen-lockfile` fails exactly as reported. Nothing consumes it — CI installs with npm on every job, the docs name no pnpm path for the repo itself, and package-lock.json is current. The market USES pnpm inside profiles; it is not developed with pnpm. A lockfile that nobody updates is worse than none: it breaks the one command that trusts it and misleads about what the project supports. Removed rather than regenerated, because regenerating it recreates the maintenance trap that produced this issue. The bundle half is measured differently than reported. At the v1.39.0 tag the committed client.js was indeed built from an older dependency set. At current HEAD a fresh `npm run build:client` reproduces the committed bundle byte-for-byte on the machine that committed it — verified before this change. What was actually missing is enforcement: `npm run check` already rebuilds the bundle in CI, and nothing failed when the rebuild differed from what was committed. Now `git diff --exit-code client/` does, on both platforms. That guard is also an experiment, stated as one: if the build embeds anything environment-dependent (the CSS module hash prefixes have drifted between machines before), this PR's own CI will say so on Linux and Windows, and that answer is worth having either way. * fix: hash CSS module classes from the repo-relative path The reproducibility guard in the previous commit did its job on its first run: check (ubuntu) rebuilt the bundle and got `.eGUBIq_root` where the committed artifact says `.SOz1_a_root`. That named the input — lightningcss derives `[hash]` from the `filename` it is given, and the plugin handed it the ABSOLUTE path, so the class prefix was a fingerprint of the checkout directory. Two builds on one machine agreed; two machines never could. The filename is now repo-relative with posix separators — the same string on every machine including Windows — so the hash depends on what the file is, not where the clone lives. The committed bundle is rebuilt under the new scheme, and the guard that caught this stays in: from here, a client PR whose artifact does not match its source fails check on both platforms. * fix: pin LF checkouts so the sourcemap can rebuild identically on Windows Second finding from the reproducibility guard: with the hash input fixed, check (ubuntu) went green and check (windows) kept failing — but only on client.js.map. The runner checks sources out under autocrlf, the sourcemap embeds them in sourcesContent, and CRLF sources can never reproduce the committed LF map. The bundle itself was already clean; the map is where checkout-time conversion leaks into a build artifact. `git add --renormalize .` under the new attributes changes nothing — the repository is already all-LF — so this pins what Windows checks out rather than rewriting anything.
14 lines
547 B
Plaintext
14 lines
547 B
Plaintext
# Source files check out with LF everywhere. Without this, a Windows
|
|
# checkout under autocrlf gets CRLF sources, the client sourcemap embeds
|
|
# them in sourcesContent, and the committed map can never match a Windows
|
|
# rebuild — the reproducibility guard measured exactly that on its second
|
|
# run (#472). The bundle itself was already line-ending-clean; the map is
|
|
# where checkout-time conversion leaks into a build artifact.
|
|
* text=auto eol=lf
|
|
# Binary-ish assets keep their bytes.
|
|
*.png -text
|
|
*.jpg -text
|
|
*.gif -text
|
|
*.ico -text
|
|
*.woff2 -text
|