[I] [website] Non-reproducible website installs from gitignored lockfiles [fluss]

["binary-signal (via GitHub)" <gi...@apache.org>]

binary-signal opened a new issue, #3502:
URL: https://github.com/apache/fluss/issues/3502

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.
   
   
   ### Fluss version
   
   main (development)
   
   ### Please describe the bug 🐞
   
   
   We gitignore both lockfiles `website/pnpm-lock.yaml` and `website/package-lock.json` (`.gitignore` lines 46 and 50), so we never commit one. That means every `npm install` re-resolves all our version ranges against whatever npm is serving that day. Builds aren't reproducible, and the tree has no integrity checking. I'd like us to commit a lockfile and have CI install from it. pnpm later is a nice bonus, but optional.
   
   
   I hit this twice in one sitting while reviewing a PR with changes in the website. A clean install pulled `@docusaurus/plugin-client-redirects` at `3.10.1` while `@docusaurus/core` stayed at `3.9.2`, and Docusaurus won't start unless every `@docusaurus/*` package matches:
   
   ```
   Error: Invalid name=docusaurus-plugin-client-redirects version number=3.10.1.
   All official @docusaurus/* packages should have the exact same version
   as @docusaurus/core (number=3.9.2).
   ```
   
   Then `@docusaurus/core` itself jumped `3.9.2 → 3.10.1` between two commands, with no edit to `package.json`. The tree moves under you, and someone has to stop and debug it each time. On top of that, a committed lockfile carries an integrity hash per package; without one, a bad transitive patch release installs silently with nothing to check it against.
   
   ## The fix
   
   1. Drop both lockfile lines from `.gitignore`.
   2. Commit the lockfile (`package-lock.json` if we stay on npm).
   3. Switch the website CI job from `npm install` to `npm ci`, which installs from the lockfile and fails if it has drifted instead of re-resolving.
   
   That's it. Builds are reproducible again and integrity checking comes back for free.
   
   ## Optional: pnpm
   
   As a follow-up, not a requirement consider migration from npm to pnpm. A strict `node_modules` (no phantom hoisted deps) rules out a class of "works on my machine" bugs, including the half-npm/half-pnpm tree that gave me a duplicate-`joi` error while poking at this. It's also faster, uses far less disk, and has `minimumReleaseAge` to refuse brand-new releases as a hedge against a compromised one. Migration is basically `corepack enable` + `pnpm import`, then pin `packageManager` in `package.json`.
   
   
   ### Solution
   
   _No response_
   
   ### Are you willing to submit a PR?
   
   - [ ] I'm willing to submit a PR!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@fluss.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org