chore: enforce npm min-release-age dependency cooldown

[joker23]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

Supply chain hardening for legacy SDK repositories, mirroring js-core's yarn npmMinimalAgeGate: 4320 (3 days).

Describe the solution you've provided

• Add .npmrc with min-release-age=3 (npm expresses this in days), so npm resolves only versions published more than 3 days ago. Unlike a Dependabot-level setting, this applies to every install — local development and CI alike.
• min-release-age-exclude explicitly names the first-party packages this repo actually resolves (launchdarkly-js-client-sdk and its transitive launchdarkly-js-sdk-common), so LaunchDarkly patches can be adopted immediately while third-party releases stay quarantined. Names are listed individually rather than pattern matched.
• .npmrc is un-ignored so the setting is committed; publishing is unaffected because setup-node writes its auth .npmrc to a temp NPM_CONFIG_USERCONFIG path, not into the repo.
• CI installs npm@^11.17.0 before npm install — min-release-age-exclude landed in npm 11.17.0, and the node 22 matrix entry bundles npm 10. The release workflow needs no change: node 24.x already bundles 11.17.0, so its Update NPM step is removed.

Describe alternatives you've considered

Dependabot cooldown — only governs Dependabot PRs, and these legacy repos aren't aiming to stay continuously updated.

Additional context

Verified locally with npm 11.17.0: the gate blocks non-exempt packages, the exclude list is honored, and npm install plus the test suite pass.

Link to Devin session: https://app.devin.ai/sessions/566f0d951dfa4568b67ad0c6c1cfb7c1
Requested by: @joker23

---

Note

Overview
Introduces supply-chain hardening by committing a repo .npmrc that sets min-release-age=3, so npm install only resolves dependency versions published more than three days ago. min-release-age-exclude lists launchdarkly-js-client-sdk and launchdarkly-js-sdk-common so first-party LaunchDarkly packages are not delayed.

.npmrc is removed from .gitignore so the policy applies in local dev and CI; publishing auth is unchanged because setup-node uses a separate user config for registry tokens.

CI and release GitHub Actions pin Node from lts/* / 24.x to ^24.19.0 (npm 11.x with min-release-age-exclude support). The global npm install -g npm@11.6.2 steps are removed from both publish jobs in release-please.yml as redundant with the pinned Node toolchain.

^{Reviewed by Cursor Bugbot for commit e62f4cb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review

[kinyoklion]

What is the full version of 24 this ends up being?

[devin-ai-integration]

24.18.0 on the latest run — setup-node takes it from the runner tool cache rather than resolving the newest 24.x (24.19.0), which is exactly why the bundled npm is 11.16.0 and the Update NPM step is back.

[kinyoklion]

Is there a way to make it be at least 24.19.0? Without pinning it to exactly 24.19.0?

[kinyoklion]

And now what version of NPM does 24.19.0 ship with?

[devin-ai-integration]

11.17.0 — verified in the run for node: '^24.19.0':

Attempting to download ^24.19.0...
Acquiring 24.19.0 - x64 from .../node-24.19.0-linux-x64.tar.gz
node: v24.19.0
npm: 11.17.0

So setup-node accepts a semver range and pulls the newest 24.x that satisfies it instead of the cached 24.18.0. With that in place I've dropped the Update NPM steps again (CI + both release jobs), and release-please now uses node-version: '^24.19.0' instead of 24.x. Same across js-client-sdk#352 / node-client-sdk#77 / vue-client-sdk#97.

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 5 additional findings in Devin Review.

[devin-ai-integration]

🟡 Dependency cooling-off period is effectively disabled because the wait time is far shorter than intended

The minimum wait before a newly published dependency may be installed is set to 3 (min-release-age=3 in .npmrc:1), but the setting is interpreted in minutes rather than days, so packages published only three minutes ago are still installed.
Impact: The safeguard meant to avoid pulling in just-published (potentially compromised) dependency versions provides almost no protection.

npm config units for min-release-age

npm's min-release-age config is a number of minutes, not days. The accompanying comments in .github/workflows/ci.yml:32 and .github/workflows/release-please.yml:50 indicate the intent is to use the exclusion list to allow LaunchDarkly's own freshly published packages, implying a meaningful cooling-off window for everything else. A 3-day window would need min-release-age=4320.

Suggested change

	min-release-age=3
	min-release-age=4320

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[kinyoklion]

Pretty sure this is days.

[devin-ai-integration]

Agreed — it's days (docs), so 3 is the intended 3-day window and the suggestion is wrong. Same conclusion as the earlier thread on node-client-sdk#77; no change needed.