Feature/security

[xurxodev]

📌 References

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

📝 Implementation

• Migrate to Vite
• Update node to 22
• Upgrade yarn 4
• Apply security patches (snyk)
• Fix network errors in console in production

🛡️ Vulnerabilities fixed

High

• axios: SSRF, CSRF, Prototype Pollution, DoS, ReDoS -> resolution 1.13.5 (+ @eyeseetea/d2-api upgraded to 1.16.0)
• follow-redirects: multiple Information Exposure / parameter handling issues via old axios chain -> removed by upgrading axios/d2-api tree
• qs: Allocation/Throttling issues -> resolution 6.14.2
• file-type: DoS/Infinite loop from 16.5.3 and new issue in 21.3.1 -> upgraded to 21.3.2
• flatted (via old log4js chain): High/Critical issues -> removed after @eyeseetea/d2-api upgrade

Medium (resolutions / upgrades)

• lodash: Prototype Pollution -> resolution 4.17.23
• glob-parent: ReDoS -> resolution 5.1.2
• node-fetch: Information Exposure / DoS (legacy chain) -> resolution 2.6.7
• jszip: Zip Slip -> upgraded to 3.8.0
• postcss (via postcss-rtl 1.x): ReDoS / Input Validation -> upgraded postcss-rtl to 2.0.0

Direct upgrade

• @dhis2/app-runtime: 3.2.4 -> 3.12.0
• @eyeseetea/d2-api: 1.9.2 -> 1.16.0
• @eyeseetea/feedback-component: 0.1.3-beta.3 -> 0.2.0

---

⚠️ Vulnerabilities not fixed (and reason)

These issues still appear as no direct upgrade or patch in the current dependency tree.

Vulnerability	Severity	Reason
babel-traverse 6.26.0 (SNYK-JS-BABELTRAVERSE-5962463)	Critical	No direct patch path in current tree. Comes from @dhis2/d2-ui-forms -> d2 -> babel-jest -> babel-plugin-istanbul -> istanbul-lib-instrument -> babel-traverse.
braces 1.8.5 (SNYK-JS-BRACES-6838727 / npm:braces:20180219)	High / Low	Fixed upstream exists, but not directly upgradable from current legacy chain (d2-ui-forms/d2/.../micromatch).
i18next 10.6.0 (SNYK-JS-I18NEXT-1065979 / 575536 / 585930)	High / Medium	Fixed versions exist (19.x), but no direct upgrade path with current @dhis2/d2-i18n@1.1.3 chain.
inflight 1.0.6 (SNYK-JS-INFLIGHT-6095116)	Medium	No fix available (legacy/unmaintained package). Path: @dhis2/d2-i18n-generate -> rimraf -> glob -> inflight.
markdown-it 12.3.2 (SNYK-JS-MARKDOWNIT-6483324)	High	Fixed upstream exists (13.0.2), but no direct upgrade path from current chain (d2-ui-forms -> d2 -> jsdoc -> markdown-it).
micromatch 2.3.11 (SNYK-JS-MICROMATCH-6838728)	Medium	Fixed upstream exists (4.0.8), but blocked by legacy dependency chain.
node-gettext 2.1.0 (SNYK-JS-NODEGETTEXT-6100943)	Medium	No patch/direct upgrade path available. Path: @dhis2/d2-i18n-extract -> i18next-conv -> node-gettext.
taffydb 2.6.2 (SNYK-JS-TAFFYDB-2992450)	High	No patch/upgrade available in current chain (d2-ui-forms -> d2 -> jsdoc -> taffydb).

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

In general, the way to fix this problem is to avoid performing a replacement that produces exactly the same string; instead, either (a) adjust the replacement so it transforms the string as intended, or (b) remove the replacement entirely if no transformation is required. This eliminates both the useless operation and the risk that the code is hiding a logic error.

Here, we want the best fix that does not change existing behavior. Right now, for any path p starting with /api, the expression p.replace(/^\/api/, "/api") returns p unchanged. Removing the rewrite function for the /api entry will preserve that behavior: by default Vite’s proxy will forward the path as-is when no rewrite is specified. This also clearly communicates that /api is intended to be proxied without alteration, and it removes the specific pattern that CodeQL is warning about.

Concretely, in vite.config.ts, within getProxy, in the returned object at lines 96–109, we will edit the /api section. We will delete the rewrite property so that the block only contains the spread of shared. No new methods or imports are required, and no other sections of the file need to be changed.

[bundlemon]

BundleMon

No change in files bundle size

Groups updated (1)

Status	Path	Size	Limits
✅	Build Folder ./**/*	10.47MB (-2.59MB -19.84%)	+20%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history | Target branch size history