Feature/security

[xurxodev]

📌 References

• Issue: Closes https://app.clickup.com/t/869bfe209 #869bfe209

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

📝 Implementation

• Migrate to vite
• Update node to 22
• Upgrade yarn 4
• Apply security patches (snyk)

🛡️ Vulnerabilities fixed

Critical

• form-data: Predictable Boundary (CVE-2025-7783) -> resolution 4.0.4

High

• axios: SSRF, CSRF, Prototype Pollution, DoS -> direct upgrade 1.13.5 + resolution 1.13.5
• @babel/runtime (e.g. via @babel/traverse chain): Incomplete List of Disallowed Inputs -> resolution 7.26.10
• i18next: Prototype Pollution (SNYK-JS-I18NEXT-1065979) -> resolution 19.8.5
• @remix-run/router (via react-router-dom): XSS (SNYK-JS-REMIXRUNROUTER-14908530) -> direct upgrade react-router-dom 6.30.3

Medium (resolutions)

• brace-expansion: ReDoS -> resolution 1.1.12
• glob-parent: ReDoS (CVE-2020-28469) -> resolution 5.1.2
• i18next: Buffer Overflow / Prototype Pollution (SNYK-JS-I18NEXT-575536, SNYK-JS-I18NEXT-585930) -> resolution 19.8.5
• lodash / lodash-es: Prototype Pollution -> resolution 4.17.23
• minimatch: ReDoS -> resolution 3.1.3
• nanoid: Improper Input Validation (CVE-2024-55565) -> resolution 3.3.8
• node-fetch: Information Exposure / DoS (SNYK-JS-NODEFETCH-2342118, SNYK-JS-NODEFETCH-674311) -> resolution 2.6.7
• path-to-regexp: ReDoS (CVE-2024-45296) -> resolution 1.9.0
• qs: Allocation/Throttling + Prototype Poisoning -> resolution 6.14.2
• diff: vulnerable transitive version -> resolution 5.2.2
• debug: vulnerable transitive version -> resolution 4.3.4
• ua-parser-js: vulnerable transitive version -> resolution 0.7.24
• jszip: vulnerable transitive version in old transitive paths -> resolution 3.7.0

Direct upgrades applied

• @dhis2/app-runtime -> 3.12.0
• @eyeseetea/feedback-component -> 0.3.0
• @material-ui/core -> 4.12.4
• @material-ui/icons -> 4.11.3
• @material-ui/styles -> 4.11.5
• axios -> 1.13.5
• lodash -> 4.17.23
• moment -> 2.29.4
• react-router-dom -> 6.30.3
• styled-jsx -> 5.0.0

---

⚠️ Vulnerabilities not fixed (and reason)

Remaining issue from the latest report (Tested 410 dependencies, 1 issue, 2 vulnerable paths):

Vulnerability	Severity	Reason
jszip@3.7.0 (Arbitrary File Write via Archive Extraction / Zip Slip, SNYK-JS-JSZIP-3188562)	Medium	Not yet fixed in this branch state. Snyk recommends upgrading to jszip@3.8.0+; current vulnerable path still resolves to 3.7.0 in 2 paths.

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

🔥 Testing

[bundlemon]

BundleMon

No change in files bundle size

Groups updated (1)

Status	Path	Size	Limits
✅	Build Folder ./**/*	1.73MB (+17.61KB +1%)	+20%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history | Target branch size history