Security patches and migrate yarn 4

[xurxodev]

📌 References

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

📝 Implementation

• Remove travis file (travis is not used anymore)
• Apply security patches using snyk
• Upgrade to yarn 4
• Fix problems to change beetween yarn 1 and yarn 4 projects
• Fix GitHub Action

Also:

• Update to latest d2-api + use 2.41 as default in app
• Set specific react/react-router-dom types to keep dependencies reproducible.
• Fix and stabilize html snapshot testing (ExampleTest)

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

🔥 Notes to the tester

[bundlemon]

BundleMon

No change in files bundle size

Groups updated (1)

Status	Path	Size	Limits
✅	Build Folder ./**/*	882.72KB (+24.92KB +2.91%)	+20%

Final result: ✅

View report in BundleMon website ➡️

---

Current branch size history | Target branch size history

[tokland]

I started deleting my old node_modules but a yarn install left some mismatches between versions of react/react-dom/react-router/dom. I've set known versions to work. Also, I did some minor improvements to the existing ExamplePage testing.

Otherwise, the yarn procedure worked for me.

[adrianq]

As discussed with @xurxodev we will try to move trivy to the github workflows repo