Phase 3 of the security remediation. Per user decision, delete newIDE/web-app/yarn.lock and keep only package-lock.json so the package manager is unambiguous (npm) and Dependabot stops double-reporting advisories for the same dep tree. Add BUILD.md documenting: - The single-lockfile rule. - The npm overrides block in newIDE/app/package.json. - How to wire scripts/security/check-lockfiles.js into CI.
1.9 KiB
Build Notes
This fork (Heretek-AI/GDevelop-Heretek) has a few build conventions that
differ from upstream — they exist to keep Dependabot alerts from piling up
again and to avoid lockfile drift.
Package manager: npm everywhere
Upstream's newIDE/web-app/ previously shipped both package-lock.json
and yarn.lock. The duplicate lockfiles meant every dependency update
generated two stale advisories, and they drifted over time. This fork uses
npm for that package and only ships package-lock.json.
Rules:
- CI must run
npm ci(notyarn install) innewIDE/web-app/. - Local development in
newIDE/web-app/should usenpm installonly. - Do not regenerate
yarn.lock—git diffshould show no such file.
If upstream re-introduces yarn.lock on a sync, delete it again in the
same PR. See Phase 3 of SECRETS.md and the original remediation plan
for the rationale.
Other manifest quirks
newIDE/app/has a non-trivialoverridesblock inpackage.json(in addition to the original@pixi/*overrides). The extra entries pin every transitive dep that has been a Dependabot alert target to a safe range. Don't remove these without re-runningscripts/security/check-lockfiles.js.GDJS/tests/uses Karma 1.7.1 (very old). It runs butnpm installwill print EBADENGINE warnings. These are harmless and are not part of this fork's scope.
Security guard
scripts/security/check-lockfiles.js asserts that no manifest pins a
known-malicious or critically-vulnerable version of the npm packages
listed in its VULNERABLE_VERSIONS / VULNERABLE_RANGES constants. Wire
this into CI:
- name: Lockfile security guard
run: node scripts/security/check-lockfiles.js
When adding a new advisory, edit the guard's constants and run it locally before opening the PR — the CI job will fail loudly if the lockfile isn't clean.