Apply security patches

[xurxodev]

📌 References

• Issue: Closes https://app.clickup.com/t/869bfeada #869bfeada
• Related PR:: Support yarn 4 projects github-workflows#5

!!!Important it's necessary merge related PR and re-build github actions to use last changes in workflows!!!

📝 Implementation

• Apply security patches
• Remove Cypress tests
• Update to node 22
• Migrate to yarn 4

🛡️ Vulnerabilities fixed

High

• axios: resolution to 1.12.0 (unify transitive 0.27.2 / 1.6.4) — SSRF (High/Medium), CSRF (High), ReDoS (Medium), resource allocation — SNYK-JS-AXIOS-*
• axios: 1.12.0 → 1.13.5 — Prototype Pollution (SNYK-JS-AXIOS-15252993)
• qs: pin to 6.14.1 (direct + resolution) — Allocation of Resources Without Limits (High) in transitive qs@6.9.7 — SNYK-JS-QS-14724253
• qs: 6.14.1 → 6.14.2 — Allocation of Resources Without Limits or Throttling (SNYK-JS-QS-15268416)
• i18next: resolution to 19.8.5 (via @dhis2/d2-i18n) — Prototype Pollution (High), Buffer Overflow (Medium) — SNYK-JS-I18NEXT-1065979, 575536, 585930

Medium

• lodash: 4.17.21 → 4.17.23 — Prototype Pollution (SNYK-JS-LODASH-15053838)
• diff: resolution to 5.2.2 — Regular Expression Denial of Service (ReDoS) (SNYK-JS-DIFF-14917201)
• Cypress removed — Fix Snyk vulnerability SNYK-JS-FORMDATA-10841150 (formdata; tests not used)

Other (stabilisation / maintenance)

• @eyeseetea/d2-api: 1.16.0-beta.13 → 1.16.0
• @octokit/rest: 18.12.0 → 20.0.2

---

⚠️ Vulnerabilities not fixed (and reason)

Vulnerability	Severity	Reason
lodash 4.17.21 (Prototype Pollution — SNYK-JS-LODASH-15053838) via @eyeseetea/d2-api@1.16.0	Medium	Transitive. Direct dep is 4.17.23; d2-api still pulls 4.17.21. Add resolution "lodash": "4.17.23" to force all paths to 4.17.23.
node-fetch 1.7.3 (Information Exposure — SNYK-JS-NODEFETCH-2342118)	Medium	Deep transitive. Path: @eyeseetea/d2-ui-components → @dhis2/d2-ui-core → d2 → isomorphic-fetch → node-fetch. Fixed in 2.6.7 / 3.1.1; no resolution or parent upgrade without breaking the UI stack.
node-fetch 1.7.3 (Denial of Service — SNYK-JS-NODEFETCH-674311)	Medium	Deep transitive. Same path as above. Fixed in 2.6.1 / 3.0.0-beta.9; same constraint.

Used plan: Migrate to Yarn 4 with coexistence in other projects

Current situation (example for this repo)

• Lockfile: yarn.lock is v1 format (Yarn Classic).
• Config: There is no .yarnrc or .npmrc; there is no packageManager or engines in package.json.
• Local dependency: "$": "link:./src" in package.json; the link: protocol is compatible with Yarn 4.
• Node: Yarn 4 requires Node 18+.

How coexistence works

Corepack (included in Node 16.10+) allows you to pin the Yarn version per project using the packageManager field in package.json. You don’t need to change the global Yarn installation on your machine.

Typical setup when you work with multiple projects:

• Use Corepack only (no global yarn installed with npm -g, uninstall it with npm uninstall -g yarn).
• Set a default Yarn 1.x for projects without packageManager:

corepack enable
corepack prepare yarn@1.22.22 --activate   # default for old projects

• In this project, declare:

"packageManager": "yarn@4.12.0"

Result:

• In this repo, yarn uses Yarn 4.12.0 (as specified in packageManager).
• In other repos without packageManager, yarn uses Yarn 1.22.22 (or whatever you activated with Corepack).

flowchart LR
  subgraph proyecto_yarn4 [This project]
    A[packageManager: yarn@4.x]
  end
  subgraph otros [Other projects]
    C[No packageManager or yarn@1]
  end
  Corepack[Corepack]
  Corepack --> A
  Corepack --> C

Loading

• In this repo: running yarn will use the version declared in packageManager (Yarn 4) via Corepack, without needing to vendor Yarn into .yarn/releases.
• In other projects: if they don’t have packageManager or have a different version, they will keep using your global Yarn (1.x or whatever they use).

Requirement: have Corepack enabled once on the machine (corepack enable). There is no need to install Yarn 4 globally.

---

Implementation steps

1. One-time machine setup (per developer)

Run this once on your machine (not per project), to let Corepack manage Yarn versions and keep Yarn 1.x as the default for old projects:

# (optional but recommended) remove globally installed Yarn
npm uninstall -g yarn

# enable Corepack (shipped with Node 16.9+ / 14.19+)
corepack enable

# set Yarn 1.x as the default for projects WITHOUT packageManager
corepack prepare yarn@1.22.22 --activate

After this, any project without packageManager will use Yarn 1.22.22, and projects with packageManager: "yarn@4.x.x" will use Yarn 4 via Corepack.

2. Migrate this project to Yarn 4

Recommended order:

1. Create a safety commit so you can revert if needed.
2. Add packageManager in package.json with an exact version (for example "yarn@4.12.0"). This way Corepack already knows which version to use before .yarn/releases exists.
3. Make sure Yarn 4 is being used in this repo (so that yarn set version runs with the right major):

corepack use yarn@4.12.0
yarn --version   # should print 4.12.0

4. Install Yarn 4 in the project (generates .yarnrc.yml and updates Yarn metadata for the project via Corepack):

yarn set version 4.12.0

5. node_modules mode: By default Yarn 4 can use PnP. To keep using node_modules (as now) and avoid large changes in tooling (Vite, etc.), in .yarnrc.yml (created with set version) keep or add:

nodeLinker: node-modules

6. Reinstall and regenerate the lockfile:

yarn install

The lockfile will be converted to Yarn 4 format (yarn.lock with a __metadata header).

There is no need to touch the "$": "link:./src" dependency; the link: protocol is still supported.

3. Update .gitignore

Add typical Yarn 4 entries so cache and installation state are not committed:

• .yarn/cache (package cache)
• .yarn/install-state.gz
• .yarn/unplugged
• .yarn/build-state.yml
• .pnp.* (if PnP is used in the future)

Note: When using Corepack and packageManager, it is not required to vendor Yarn into .yarn/releases. This project relies on Corepack to provide the right Yarn version.

4. Scripts and lifecycle

• postinstall (yarn localize): Still supported in Yarn 4; no changes required.
• There are no custom pre/post hooks that need to be rewritten according to the migration guide.

5. Documentation

In README.md you can add a short section under Setup to explain that the project uses Yarn 4 + Corepack and how to fix conflicts with a global Yarn 1. For example:

## Setup

```bash
$ nvm use # uses node version in .nvmrc
$ yarn install
```

This project uses Yarn 4 managed by Corepack and declares:

"packageManager": "yarn@4.12.0"

If you have Yarn 1 globally and see a packageManager error

If running yarn shows an error like:

This project's package.json defines "packageManager": "yarn@4.12.0". However the current global version of Yarn is 1.22.x.

do the following once on your machine:

# 1) Remove global Yarn (optional but recommended)
npm uninstall -g yarn

# 2) Enable Corepack (shipped with Node 16.9+ / 14.19+)
corepack enable

# 3) Set Yarn 1.x as the default for projects WITHOUT packageManager
corepack prepare yarn@1.22.22 --activate

Then, in this project (normal case, once Corepack is enabled):

nvm use
yarn install

If for some reason yarn --version still shows 1.x inside this repo, you can force Yarn 4 explicitly:

corepack use yarn@4.12.0
yarn --version   # should now print 4.12.0
yarn install

---

#### Summary of files to update

| File                         | Changes                                                                                                 |
| ---------------------------- | ------------------------------------------------------------------------------------------------------- |
| [package.json](package.json) | Add `"packageManager": "yarn@4.x.x"` (exact version).                                                   |
| `.yarnrc.yml`                | Created by `yarn set version 4`; add `nodeLinker: node-modules` if you want to keep using node_modules. |
| [yarn.lock](yarn.lock)       | Regenerated by `yarn install` (Yarn 4 format).                                                          |
| [.gitignore](.gitignore)     | Add `.yarn/cache`, `.yarn/install-state.gz`, `.yarn/unplugged`, `.yarn/build-state.yml`.                |

---

#### Expected behavior

-   **In this project**: `yarn install`, `yarn build`, `yarn start`, etc. use Yarn 4.
-   **In other projects** (without `packageManager` or with a different version): they keep using whatever Yarn version they already have (1.x, 3.x, etc.) and are not affected by this migration.

If you want Yarn 4 in another project in the future, repeat `packageManager` + `yarn set version 4` there and Corepack will ensure Yarn 4 is used only when you are inside that project.

📹 Screenshots/Screen capture

🔥 Is there anything the reviewer should know to test it?

📑 Others

• Any change in the GUI library? If so, what branch/PR?

• Any change in the D2 Api? If so, what branch/PR?

[bundlemon]

BundleMon

No change in files bundle size

Groups updated (1)

Status	Path	Size	Limits
✅	Build Folder ./**/*	2.75MB (-35.26KB -1.24%)	+20%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history | Target branch size history

[xurxodev]

@adrianq conflicts solved!