Address all known vulnerabilities

[aarsilv]

See commit 7dac7b2 for full per-package detail and verification notes. Summary:

• yarn audit: 112 paths → 0 (was 2 Critical / 59 High / 44 Moderate / 7 Low).
• Resolutions trimmed from 12 → 2. The previous round had scoped overrides for minimatch, brace-expansion, diff, flatted, lodash, path-to-regexp, picomatch, qs, plus schema-utils/ajv and ajv-formats/ajv. After the dep bumps below, every one of those clears transitively. The two that remain in package.json:
  • @types/node ^20.0.0 — intentional pin to keep the dev type surface aligned with engines.node >=20.x. Not a vuln fix.
  • @tootallnate/once ^3.0.1 — GHSA-rj4j-rrv4-3xc4 (low). Pulled by @google-cloud/storage → teeny-request → http-proxy-agent. The latest @google-cloud/storage 7.19.x still ships the unpatched chain and there's no newer release; the chain is dev-only (test-fixture downloader).
• Direct dep bumps: @eppo/js-client-sdk-common 4.15.2 → ^5 (drops uuid runtime dep, replaced upstream with crypto.randomUUID for event IDs), express ^4 → ^5 (drops vulnerable path-to-regexp 0.x and qs <6.15 transitively without needing scoped resolutions; express is a devDep used only by the mock API server in tests, where the simple app.get(regex, handler) usage works the same in v5), @typescript-eslint/* 5 → 8, eslint-config-prettier 8 → 10, eslint-plugin-promise 6 → 7, husky 6 → 9, lint-staged 12 → 16, prettier 2 → 3 (drops the yaml@1.x transitive that triggered the yaml advisory), @google-cloud/storage to latest 7.x.
• Two small source-side adjustments forced by the typescript-eslint v8 rule renames: bare catch for an unused catch (error) parameter in src/util/index.ts, and replacing deprecated no-var-requires disable directives with no-require-imports.

Test plan

• CI runs yarn lint, yarn typecheck, yarn test (115 tests) green on Node 20/22/24
• yarn audit reports 0 vulnerabilities
• yarn tsc (build) succeeds; dist/ exports unchanged

Manual verification

Built a tiny toy node app that consumes this branch's SDK via a file: reference and calls init(...).getStringAssignment(...) against an Eppo Sandbox account. Resolved My-Flag (with attrs {accountId, sd:'dsf'} to hit the 50/50 allocation) and megan-test-blahh for 12 distinct subject keys, comparing against the same 12 subjects in a parallel toy browser app on js-client-sdk PR #284's branch. All 12 subjects produced identical variation assignments across the two SDK branches, distribution 8 treatment / 4 control, assignment-logger fired correctly on both sides.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR focuses on eliminating dependency vulnerabilities and modernizing the repo’s tooling/runtime dependencies, while making small source tweaks required by updated lint rules.

Changes:

• Updated a large set of dependencies (including @eppo/js-client-sdk-common to ^5, express to ^5, tooling like prettier/eslint/@typescript-eslint/*) and refreshed yarn.lock.
• Reduced the number of resolutions overrides, keeping only @types/node and @tootallnate/once.
• Updated a few lint-related call sites (e.g., bare catch, updated ESLint disable rule name).

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
yarn.lock	Lockfile refresh reflecting dependency/toolchain upgrades and vulnerability remediation.
package.json	Dependency/devDependency upgrades, version bump, and pared-down resolutions.
src/util/index.ts	Removes unused catch binding to satisfy updated linting rules.
src/sdk-data.ts	Updates ESLint disable directive for require(...) to the new rule name.
src/index.spec.ts	Updates ESLint disable directives where require('.') is intentionally used in tests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[aarsilv]

From Claude: the published-package concern is unfounded — resolutions is not honored on installed packages. npm and yarn both deliberately ignore the resolutions field of any dependency in node_modules; only the field in the root project's package.json controls dependency resolution. So while these "//<key>" entries do get published into the package's package.json, they never affect a downstream consumer's install graph or behavior. They're essentially dead bytes for anyone who installs @eppo/node-server-sdk.

What's left after that is a developer-experience consideration: yarn does emit one warning per pseudo-comment key during yarn install here (Resolution field "//@types/node" does not end with a valid package name and will be ignored). The trade-off we picked, in line with visual-editor and sdk-test-data's vuln-cleanup PRs, is that having the GHSA reasoning inline next to each resolution is more useful for the next person who has to revisit them than the cost of two install-time warnings. Happy to convert these to comments above the block in a sibling RESOLUTIONS.md if there's a preference for that convention instead.

[sameerank]

Approving, but please consider re-adding the lower bounds on the version constraints

[sameerank]

Unless we're intentionally allowing downgrades to older versions (I only see versions going up in the yarn.lock), why are we loosening the lower bounds on these versions, i.e. dropping the minimum minor/patch constraints?