Lockfile hygiene: nothing ignores or rejects non-npm lockfiles #45

The repo commits package-lock.json (root) and demo/package-lock.json, CI runs npm ci, and CONTRIBUTING.md documents npm install throughout — npm is clearly the intended package manager.

But .gitignore doesn't mention any other lockfile:

https://github.com/unlayer/react-image-editor/blob/628b507/.gitignore

*.log
.DS_Store
node_modules
.cache
.history
dist
/coverage

So a contributor who runs bun install (or pnpm/yarn) ends up with an untracked bun.lock / pnpm-lock.yaml / yarn.lock sitting in git status, ready to be swept into a commit by git add . — and a demo/package-lock.json modified in place by the foreign resolver. Two lockfiles in the tree is exactly the state that makes npm ci fail confusingly for the next person.

I hit this on a fresh clone: bun.lock, demo/bun.lock untracked and demo/package-lock.json dirty, with nothing in the repo signalling that was wrong.

Suggested fix

Either:

• Ignore them — add bun.lock, bun.lockb, pnpm-lock.yaml, yarn.lock to .gitignore, or
• Refuse them — add a packageManager field to package.json (Corepack) and/or an engines.npm constraint, so the wrong tool fails loudly instead of quietly producing a second lockfile.

Ideally both, plus a line in CONTRIBUTING.md stating npm is the supported package manager — it currently says npm install but never says npm is required.