[website] Non-reproducible website installs from gitignored lockfiles

Start with .gitignore lines 46 and 50, then inspect website/package.json and the website CI job that currently runs npm install. Remove the lockfile ignores, commit website/package-lock.json, and change CI to npm ci; done means clean website installs use the committed lockfile and fail on dependency drift.

Search before asking

• I searched in the 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!