Feature/security

[xurxodev]

📌 References

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

📝 Implementation

• Migrate to vite
• Apply security patches (snyk)
• Update node to 22
• Upgrade yarn 4
• add git hooks
• remove cypress
• remove travis

🛡️ Vulnerabilities fixed / mitigated

The items below are mitigated in this repository via direct upgrades and/or Yarn resolutions (forced transitive versions).

Critical

• @babel/runtime (Babel runtime hardening) → resolution 7.26.10

High

• axios (multiple advisories in older versions) → direct + resolution 1.13.5
• form-data (advisories in older versions) → resolution 4.0.4

Medium (resolutions)

• brace-expansion → resolution 1.1.13
• glob-parent → resolution 5.1.2
• handlebars → resolution 4.7.9
• json5 → resolution 1.0.2
• lodash → resolution 4.18.1
• minimatch → resolution 3.1.3
• minimist → resolution 1.2.6
• moment → resolution 2.30.1
• nanoid → resolution 3.3.8
• node-fetch → resolution 2.6.7
• path-to-regexp → resolution 1.9.0
• qs → resolution 6.14.2
• semver → resolution 7.5.2
• underscore → resolution 1.13.8

Notes

• This section reflects what is pinned/forced by package.json#resolutions in this repo.

---

⚠️ Vulnerabilities not fixed (and reason)

The items below are still reported by corepack yarn npm audit --recursive and/or remain present in yarn.lock.

Some have no patch available in the affected major line; others require upstream upgrades/removals (tooling or major version bumps).

Vulnerability	Severity	Reason
inflight 1.0.6 (Missing Release of Resource after Effective Lifetime — SNYK-JS-INFLIGHT-6095116)	Medium	No fix available for inflight (unmaintained). Present in lockfile (inflight@1.0.6).
node-gettext 2.1.0 (Prototype Pollution — SNYK-JS-NODEGETTEXT-6100943)	Medium	No patched version published for the version range pulled in by current tooling. Present in lockfile (node-gettext@2.1.0).
vite 4.5.3 (multiple dev-server/security advisories)	Moderate/Low	Current repo pins Vite to 4.5.3. Audit still reports multiple Vite advisories that require upgrading Vite to a newer patched release.
@babel/traverse (via legacy babel-eslint)	Critical	Audit reports vulnerable @babel/traverse pulled by deprecated babel-eslint. Requires migrating away from babel-eslint (e.g. to @babel/eslint-parser) and/or upgrading the Babel toolchain.
node-forge (via google-p12-pem)	High	Audit reports vulnerable node-forge pulled by google-p12-pem. Requires upgrading/removing the dependency chain that brings it in.
babel-traverse 6.26.0 (SNYK-JS-BABELTRAVERSE-5962463)	Critical	No upgrade or patch available in the babel-traverse@6 line. Path (Snyk): @dhis2/d2-ui-forms@7.3.3 → d2@31.1.1 → babel-jest@22.4.4 → babel-plugin-istanbul@4.1.6 → istanbul-lib-instrument@1.10.2 → babel-traverse@6.26.0
braces 1.8.5 (SNYK-JS-BRACES-6838727, npm:braces:20180219)	High / Low	Fixed in newer majors (2.3.1 / 3.0.3), but current path pulls 1.x. Path (Snyk): @dhis2/d2-ui-forms@7.3.3 → d2@31.1.1 → babel-jest@22.4.4 → babel-plugin-istanbul@4.1.6 → test-exclude@4.2.3 → micromatch@2.3.11 → braces@1.8.5.
markdown-it 10.0.0 (SNYK-JS-MARKDOWNIT-2331914, SNYK-JS-MARKDOWNIT-6483324)	Medium / High	Fixed in 12.3.2 / 13.0.2. Current path (Snyk): @dhis2/d2-ui-forms@7.3.3 → d2@31.1.1 → jsdoc@3.6.7 → markdown-it@10.0.0.
marked 2.1.3 (SNYK-JS-MARKED-2342073, SNYK-JS-MARKED-2342082)	Medium	Fixed in 4.0.10. Current path (Snyk): @dhis2/d2-ui-forms@7.3.3 → d2@31.1.1 → jsdoc@3.6.7 → marked@2.1.3.
micromatch 2.3.11 (SNYK-JS-MICROMATCH-6838728)	Medium	Fixed in 4.0.8. Current path (Snyk): @dhis2/d2-ui-forms@7.3.3 → d2@31.1.1 → babel-jest@22.4.4 → babel-plugin-istanbul@4.1.6 → test-exclude@4.2.3 → micromatch@2.3.11.
taffydb 2.6.2 (SNYK-JS-TAFFYDB-2992450)	High	No upgrade or patch available per Snyk. Path (Snyk): @dhis2/d2-ui-forms@7.3.3 → d2@31.1.1 → jsdoc@3.6.7 → taffydb@2.6.2.

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.4MB (-2.85MB -67.07%)	+20%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history | Target branch size history