chore: resolve open dependabot security alerts

[jonathannorris]

Summary

• Bumped `axios` from `1.15.0` to `^1.15.2` (direct dependency)
• Removed root `overrides` block — overrides only affect this monorepo's dev environment and aren't inherited by consumers of any published package
• Root `package-lock.json` upgraded from lockfileVersion 2 → 3 (17 of 22 lockfiles in the repo are already v3; CI matrix uses Node 20/22/24, all of which ship with npm 10+; release pipeline explicitly pins npm `^11.5.1`)

Dependabot Alerts Resolved

Alert	Package	Severity	Fix
#255, #254, #253, #252	`fast-uri`	high	Resolved naturally to `3.1.2`
#251, #250, #249, #248	`fast-xml-builder`	high/medium	Resolved naturally to `1.1.7`
#247-#235	`axios`	high/medium/low	Bumped direct dep to `^1.15.2`

Remaining Open Alerts (dev tooling only)

Alert(s)	Package	Severity	Root cause
#256	`@babel/plugin-transform-modules-systemjs`	high	`nx@22.7.1` pulls in a vulnerable version
#217	`follow-redirects`	medium	`nx@22.7.1` pins `1.15.11` exactly
#135	`minimatch`	high	transitively via `verdaccio`'s `@verdaccio/core`
#202, #201, #101	`lodash`	high/medium	`@verdaccio/local-storage-legacy` pins an older version

These will resolve as `nx` and `verdaccio` release updates with patched transitive deps.

Notes

• `axios@1.15.0` in `nx/node_modules/` remains unpatched — `nx@22.7.1` (latest) pins this version exactly and npm nested overrides cannot override it when a direct dep with the same name exists at root.

[MattIPv4]

Same thought as in the other PR, do we need to keep the overrides, or can they be removed now that the lockfiles have been bumped?

[gemini-code-assist]

Code Review

This pull request updates several dependencies across the monorepo, including axios, fast-xml-builder, fast-uri, and json-logic-engine, and introduces dependency overrides to address security vulnerabilities. Feedback identifies that the lodash version 4.18.0 specified in the overrides does not exist and should be corrected to 4.17.21. Furthermore, the overrides in sub-packages are redundant as they are already defined in the root package.json and will be ignored by npm. Additionally, the major version update for json-logic-engine in flagd-core should be synchronized with the root configuration to maintain consistency across the workspace.

[jonathannorris]

Removing the overrides block from root package.json. These only affect the monorepo's dev environment — they're not inherited by consumers of any published package, so they don't improve security posture for SDK users.

The following alerts remain open, all tied to dev tooling we don't control:

Alert(s)	Package	Severity	Root cause
#256	@babel/plugin-transform-modules-systemjs	High	nx@22.7.1 pulls in a vulnerable version
#217	follow-redirects	Medium	nx@22.7.1 pins 1.15.11 exactly
#135	minimatch	High	transitively via verdaccio's @verdaccio/core
#202, #201, #101	lodash	High/Medium	@verdaccio/local-storage-legacy pins an older version

These will resolve as nx and verdaccio release updates with patched transitive deps.

[MattIPv4]

The bump to the v3 lockfile makes this PR pretty unreviewable, and it looks like the lockfile isn't actually valid? How was it generated?

[jonathannorris]

@MattIPv4 yea the lock file change does make this hard to review. I'll try and revert that, it seemed fairly safe based on this research:

Root `package-lock.json` upgraded from lockfileVersion 2 → 3 (17 of 22 lockfiles in the repo are already v3; CI matrix uses Node 20/22/24, all of which ship with npm 10+; release pipeline explicitly pins npm `^11.5.1`)

[MattIPv4]

Yeh, I think v2 -> v3 should be safe, but it doesn't seem like it was done correctly here? I'd probably lean toward just resolving the security alerts in this PR, keeping it v2, and then doing the v2 -> v3 in a dedicated PR with a reproducible command so we can verify it is just a format change and not including any dependency changes.

[toddbaert]

Did you use the nx migrate command for this? If not, I would suggest not touching NX deps. They often come with specific migration scripts only run with the above command.

[jonathannorris]

yea, nx migrate wasn't used here. The intent was to pull in tmp@0.2.6 (alert #264), but nx@20.3.1 already declares tmp: ~0.2.1, which covers 0.2.6 — so a lockfile-only bump would've been enough. I'll revert the NX changes and use npm update tmp instead.

[jonathannorris]

actually, scratch that — nx@22.7.2 (already on the branch from a prior merge) pins tmp at exactly 0.2.4, so there's no range to exploit with a lockfile-only bump. The 22.7.2 → 22.7.5 bump was necessary to get tmp@0.2.6. I ran nx migrate 22.7.5 locally to verify — no migration scripts exist between those two versions, so the bare version bump is equivalent.