Bug 40778 - Manage, upgrade and audit npm packages in a structured manner
Summary: Manage, upgrade and audit npm packages in a structured manner
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-09 19:17 UTC by Paul Derscheid
Modified: 2025-11-07 08:37 UTC (History)
1 user (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 40778: Pin Node.js dependencies to exact resolved versions (5.77 KB, patch)
2025-11-06 17:38 UTC, Paul Derscheid
Details | Diff | Splinter Review
Bug 40778: Update yarn.lock (58.55 KB, patch)
2025-11-06 17:38 UTC, Paul Derscheid
Details | Diff | Splinter Review
Bug 40778: Introduce modular Node.js dependency auditing framework (107.16 KB, patch)
2025-11-06 17:38 UTC, Paul Derscheid
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Derscheid 2025-09-09 19:17:03 UTC
This bug is meant to collect things that need to be done to safely manage, upgrade and audit npm packages in Koha.
Comment 1 Paul Derscheid 2025-11-06 17:38:44 UTC
Created attachment 189192 [details] [review]
Bug 40778: Pin Node.js dependencies to exact resolved versions

- Replace all caret ranges (^) in package.json with exact versions
    - 37 dependencies pinned to exact versions
    - 32 devDependencies pinned to exact versions
    - 2 resolutions updated to exact versions
- This ensures reproducible builds by locking dependencies to their currently resolved versions from yarn.lock
- This also ensures that we don't update to a compromised package by accident just by running `yarn install` without `--frozen-lockfile`
Comment 2 Paul Derscheid 2025-11-06 17:38:46 UTC
Created attachment 189193 [details] [review]
Bug 40778: Update yarn.lock
Comment 3 Paul Derscheid 2025-11-06 17:38:48 UTC
Created attachment 189194 [details] [review]
Bug 40778: Introduce modular Node.js dependency auditing framework

- Add a complete Node.js dependency management and audit framework under
Koha/Devel/Node/, supporting npm and Yarn via a strategy-based design
- Unified command-line tools for outdated, audit, SBOM, and Bugzilla reports
- Extensible package manager abstraction (Npm, Yarn)
- Structured JSON output and CycloneDX-like SBOM generation
- Compromise detection for quick checks if security breaches are announced
- Integrated CI helper

To test:
1. Run `./misc/devel/node_audit_dependencies.pl --help` to verify tool availability.
2. Execute `--outdated` and `--audit` modes to ensure JSON output and summary files are generated.
3. Generate reports:
   - `--sbom` → creates `node_modules_sbom.xml`
   - `--bugzilla` → creates `dependency_bugzilla_report.md`
4. Optionally test compromise detection:
   `./misc/devel/node_audit_compromise.pl --inline "lodash@4.17.21"`
5. Sign off.
Comment 4 Paul Derscheid 2025-11-07 08:25:46 UTC
Some additional info:
- Did not use @cyclonedx/yarn-plugin-cyclonedx for the sbom because it requires yarn berry (v4) as a minimum.
- Designed the scripts around exit codes and artifacts since they're intended for CI, which might be unintuitive compared to other scripts in our repo. Seemed like the right choice.
- Should plug right into build.pl with an additional option, but I haven't tested that yet, might need more tweaks if it doesn't behave as I expect.
Comment 5 Paul Derscheid 2025-11-07 08:37:59 UTC
I am also not sure yet, whether the template for the bugzilla report makes sense as it is.

I thought about splitting this by severity. But on the other hand, we probably don't want to scatter dozens of bugs that all just address a single dependency update.

So keeping this in one bug "per run" with findings and updating with patches per finding is probably cleaner.

Not sure yet, whether this should be automated, or if it's better if a person (me for example :)) just takes the report and manually creates a bug after the run and only creates a new one if new findings pop up.

In summary, I am not sure yet about the actual workflow based on this, but would recommend:
- CI runs:
  - Audit lists
    - Vulnerable packages
    - Outdated packages
  - Report is generated
  - Is translated into a Bug
  - Then start fixing by severity what is easily fixable (no major version upgrades)
  - Create targeted bugs for vulnerable packages that need a major upgrade
  - Then start fixing the outdated ones in the same manner
  - Every action depends a bit on whether the dependency is actually in the production build or just a devDependency (we need to maybe review if these are sorted into the right bins right now)
  - Production dependencies need to be prioritized
  - Dev dependencies can be evaluated after
- Once we did the initial cleanup, this will surface a lot less issues but I am not sure how long this will take
  - We already have some deps, where we are 3 major versions behind
  - This then also requires the dev to review upstream what actually happened
  - If we depend on something outdated that requires a big refactor and it's not vulnerable in a way that's actually exploitable, it's debatable of whether it's worth the effort to upgrade