Feature/security#394
Merged
Merged
Conversation
- Enable core pack in prepare script - Add packageManager in package.json - Install Yarn 4 in the project - Update .gitignore - Update README
…time Upgrade vulnerable direct dependencies flagged by Snyk, including @dhis2/app-runtime, @eyeseetea/feedback-component, @material-ui/*, axios, lodash, moment, react-router-dom and styled-jsx. Adjust runtime integration after upgrades (Provider props for app-runtime, lodash import in MetadataService, and Vite __dirname define for styled-jsx) so build and tests remain green.
Upgrade direct dependencies flagged by Snyk, including @dhis2/app-runtime, @eyeseetea/feedback-component, @material-ui/*, axios, lodash, moment, react-router-dom and styled-jsx. Add dependency resolutions to force secure transitive versions for: axios, @babel/runtime, i18next, brace-expansion, form-data, glob-parent, lodash, minimatch, nanoid, node-fetch, path-to-regexp and qs.
- @babel/runtime, i18next, brace-expansion, form-data, glob-parent, lodash-es, minimatch, nanoid, node-fetch, path-to-regexp, qs, diff, debug, ua-parser-js, jszip (and axios aligned across the tree where applicable) Tests
Replace the shell loop in `update-po` with a `find -exec` based command to avoid `spawn ENOTDIR` under Corepack/Yarn 4 during pre-push.
BundleMonNo change in files bundle size Groups updated (1)
Final result: ✅ View report in BundleMon website ➡️ |
Ramon-Jimenez
requested changes
Jun 11, 2026
There was a problem hiding this comment.
@xurxodev A couple of things on this one, tested on v42:
- yarn build fails due to a reference to
D2ApiDefaultpackage being imported from d2-api (which is also provoking a conflict withdevelopment) - After removing this reference and building the app, it compiles and gets installed but when trying to import any Bulk Load template, it throws an error
_ is not defined
Thanks!
Author
|
@Ramon-Jimenez for me It's working. This PR use yarn 4 and it's necessary: |
|
@xurxodev It does build if you use incoming change instead of what is currently in In any case, even after the build, the 
|
…mport `toDetails()` used `_.pick` without importing lodash, causing `ReferenceError: _ is not defined` when saving history after a template import in the Vite production bundle.
Author
|
@Ramon-Jimenez Merged with development, fixed the bug and testing importing a file |
|
@xurxodev Thanks. It is now possible to import templates, but for some reason it seems we lost the modal window that prompts when data is already available in the dataset for the same periods. This one: 
It is displaying on v40 but not on v42. I guess we haven't lost this feature as part of this PR, but in any case please let's fix it. |
|
Approving this one, will move issue about modal window disappearing on v42 to another specific ticket. |
Ramon-Jimenez
approved these changes
Jun 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📌 References
!!!Important it's necessary merge related PR and re-build github actions to use last changes in workflows!!!
📝 Implementation
🛡️ Vulnerabilities fixed
Critical
form-data: Predictable Boundary (CVE-2025-7783) ->resolution 4.0.4High
axios: SSRF, CSRF, Prototype Pollution, DoS ->direct upgrade 1.13.5+resolution 1.13.5@babel/runtime(e.g. via@babel/traversechain): Incomplete List of Disallowed Inputs ->resolution 7.26.10i18next: Prototype Pollution (SNYK-JS-I18NEXT-1065979) ->resolution 19.8.5@remix-run/router(viareact-router-dom): XSS (SNYK-JS-REMIXRUNROUTER-14908530) ->direct upgrade react-router-dom 6.30.3Medium (resolutions)
brace-expansion: ReDoS ->resolution 1.1.12glob-parent: ReDoS (CVE-2020-28469) ->resolution 5.1.2i18next: Buffer Overflow / Prototype Pollution (SNYK-JS-I18NEXT-575536,SNYK-JS-I18NEXT-585930) ->resolution 19.8.5lodash/lodash-es: Prototype Pollution ->resolution 4.17.23minimatch: ReDoS ->resolution 3.1.3nanoid: Improper Input Validation (CVE-2024-55565) ->resolution 3.3.8node-fetch: Information Exposure / DoS (SNYK-JS-NODEFETCH-2342118,SNYK-JS-NODEFETCH-674311) ->resolution 2.6.7path-to-regexp: ReDoS (CVE-2024-45296) ->resolution 1.9.0qs: Allocation/Throttling + Prototype Poisoning ->resolution 6.14.2diff: vulnerable transitive version ->resolution 5.2.2debug: vulnerable transitive version ->resolution 4.3.4ua-parser-js: vulnerable transitive version ->resolution 0.7.24jszip: vulnerable transitive version in old transitive paths ->resolution 3.7.0Direct 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.5axios->1.13.5lodash->4.17.23moment->2.29.4react-router-dom->6.30.3styled-jsx->5.0.0Remaining issue from the latest report (
Tested 410 dependencies,1 issue,2 vulnerable paths):jszip@3.7.0(Arbitrary File Write via Archive Extraction / Zip Slip,SNYK-JS-JSZIP-3188562)jszip@3.8.0+; current vulnerable path still resolves to3.7.0in 2 paths.Used plan: Migrate to Yarn 4 with coexistence in other projects
Current situation (example for this repo)
.yarnrcor.npmrc; there is nopackageManagerorenginesin package.json."$": "link:./src"in package.json; thelink:protocol is compatible with Yarn 4.How coexistence works
Corepack (included in Node 16.10+) allows you to pin the Yarn version per project using the
packageManagerfield inpackage.json. You don’t need to change the global Yarn installation on your machine.Typical setup when you work with multiple projects:
yarninstalled withnpm -g, uninstall it withnpm uninstall -g yarn).packageManager:Result:
yarnuses Yarn 4.12.0 (as specified inpackageManager).packageManager,yarnuses 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 --> Cyarnwill use the version declared inpackageManager(Yarn 4) via Corepack, without needing to vendor Yarn into.yarn/releases.packageManageror 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:
After this, any project without
packageManagerwill use Yarn 1.22.22, and projects withpackageManager: "yarn@4.x.x"will use Yarn 4 via Corepack.2. Migrate this project to Yarn 4
Recommended order:
packageManagerin package.json with an exact version (for example"yarn@4.12.0"). This way Corepack already knows which version to use before.yarn/releasesexists.yarn set versionruns with the right major):corepack use yarn@4.12.0 yarn --version # should print 4.12.0.yarnrc.ymland updates Yarn metadata for the project via Corepack):yarn set version 4.12.0node_modules(as now) and avoid large changes in tooling (Vite, etc.), in .yarnrc.yml (created withset version) keep or add:The lockfile will be converted to Yarn 4 format (yarn.lock with a
__metadataheader).There is no need to touch the
"$": "link:./src"dependency; thelink: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)4. Scripts and lifecycle
yarn localize): Still supported in Yarn 4; no changes required.pre/posthooks 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:
This project uses Yarn 4 managed by Corepack and declares:
If you have Yarn 1 globally and see a packageManager error
If running
yarnshows an error like:do the following once on your machine:
Then, in this project (normal case, once Corepack is enabled):
If for some reason
yarn --versionstill shows1.xinside this repo, you can force Yarn 4 explicitly:corepack use yarn@4.12.0 yarn --version # should now print 4.12.0 yarn install📹 Screenshots/Screen capture
🔥 Testing