chore(deps): bump posthog-node from 5.37.1 to 5.46.1 in the production-dependencies group across 1 directory

[dependabot]

Bumps the production-dependencies group with 1 update in the / directory: posthog-node.

Updates posthog-node from 5.37.1 to 5.46.1

Release notes

Sourced from posthog-node's releases.

posthog-node@5.46.1

5.46.1

Patch Changes

• #4234 6c8fde0 Thanks @​hpouillot! - Normalize V8 Promise combinator stack frames so input indexes are not treated as source filenames. (2026-07-23)
• Updated dependencies [6c8fde0]:
  • @​posthog/core@​1.45.1

posthog-node@5.46.0

5.46.0

Minor Changes

• #4172 9621830 Thanks @​haacked! - send minimal $feature_flag_called events when the server enables it

  When the v2 /flags response carries minimalFlagCalledEvents: true (or, for posthog-node local evaluation, the flag-definitions payload carries minimal_flag_called_events: true) and the evaluated flag is not linked to an experiment ($feature_flag_has_experiment === false), $feature_flag_called events are rebuilt from a strict allowlist of flag-evaluation, processing-control, and SDK-identity properties. Super properties, $set/$set_once, the $feature/<key> enumeration, $active_feature_flags, and the context envelope are stripped. Any missing signal (no gate on the response, bootstrapped or locally injected flags, has_experiment unknown) falls back to the full event, and experiment-linked flags always send the full envelope. The gate is stored alongside the cached flags (posthog-js persistence, posthog-node poller state) and is server-controlled, with no SDK-side configuration. before_send runs after the filter and may re-add stripped properties. (2026-07-20)

Patch Changes

• Updated dependencies [9621830]:
  • @​posthog/core@​1.44.0

posthog-node@5.45.2

5.45.2

Patch Changes

• #4168 06d19a2 Thanks @​dustinbyrne! - Avoid Next.js Edge runtime warnings for native compression and fatal error handling. (2026-07-16)
• Updated dependencies [06d19a2]:
  • @​posthog/core@​1.43.1

posthog-node@5.45.1

5.45.1

Patch Changes

• #4164 9eb2b28 Thanks @​dustinbyrne! - Fix the default Node.js event flush interval at 5 seconds. (2026-07-16)

posthog-node@5.45.0

5.45.0

Minor Changes

• #4159 fad6d9a Thanks @​haacked! - add $feature_flag_has_experiment to $feature_flag_called events

  $feature_flag_called events now carry a $feature_flag_has_experiment boolean sourced from the server's has_experiment flag metadata (the /flags?v=2 response for remote evaluation, the /api/feature_flag/local_evaluation definitions for posthog-node local evaluation). The property is only sent when the server explicitly reports has_experiment; it is omitted entirely when the value is unknown (older servers, missing metadata, bootstrapped or locally injected flags). (2026-07-16)

... (truncated)

Changelog

Sourced from posthog-node's changelog.

5.46.1

Patch Changes

• #4234 6c8fde0 Thanks @​hpouillot! - Normalize V8 Promise combinator stack frames so input indexes are not treated as source filenames. (2026-07-23)
• Updated dependencies [6c8fde0]:
  • @​posthog/core@​1.45.1

5.46.0

Minor Changes

• #4172 9621830 Thanks @​haacked! - send minimal $feature_flag_called events when the server enables it

  When the v2 /flags response carries minimalFlagCalledEvents: true (or, for posthog-node local evaluation, the flag-definitions payload carries minimal_flag_called_events: true) and the evaluated flag is not linked to an experiment ($feature_flag_has_experiment === false), $feature_flag_called events are rebuilt from a strict allowlist of flag-evaluation, processing-control, and SDK-identity properties. Super properties, $set/$set_once, the $feature/<key> enumeration, $active_feature_flags, and the context envelope are stripped. Any missing signal (no gate on the response, bootstrapped or locally injected flags, has_experiment unknown) falls back to the full event, and experiment-linked flags always send the full envelope. The gate is stored alongside the cached flags (posthog-js persistence, posthog-node poller state) and is server-controlled, with no SDK-side configuration. before_send runs after the filter and may re-add stripped properties. (2026-07-20)

Patch Changes

• Updated dependencies [9621830]:
  • @​posthog/core@​1.44.0

5.45.2

Patch Changes

• #4168 06d19a2 Thanks @​dustinbyrne! - Avoid Next.js Edge runtime warnings for native compression and fatal error handling. (2026-07-16)
• Updated dependencies [06d19a2]:
  • @​posthog/core@​1.43.1

5.45.1

Patch Changes

• #4164 9eb2b28 Thanks @​dustinbyrne! - Fix the default Node.js event flush interval at 5 seconds. (2026-07-16)

5.45.0

Minor Changes

• #4159 fad6d9a Thanks @​haacked! - add $feature_flag_has_experiment to $feature_flag_called events

  $feature_flag_called events now carry a $feature_flag_has_experiment boolean sourced from the server's has_experiment flag metadata (the /flags?v=2 response for remote evaluation, the /api/feature_flag/local_evaluation definitions for posthog-node local evaluation). The property is only sent when the server explicitly reports has_experiment; it is omitted entirely when the value is unknown (older servers, missing metadata, bootstrapped or locally injected flags). (2026-07-16)

Patch Changes

• Updated dependencies [fad6d9a]:
  • @​posthog/core@​1.43.0

... (truncated)

Commits

• 7c00f92 chore: update versions and lockfile [version bump]
• 34a03e2 chore: update versions and lockfile [version bump]
• 9621830 feat(flags): minimize $feature_flag_called events for non-experiment flags (#...
• 8bf1b19 chore: ban object-literal type assertions in package sources (#4192)
• be17ec1 chore: update versions and lockfile [version bump]
• 06d19a2 fix: avoid Next.js Edge runtime warnings (#4168)
• 60c2492 chore: update versions and lockfile [version bump]
• 9eb2b28 fix(node): standardize flush interval default (#4164)
• be5249f fix(docs): exclude internal members and tag deprecated ones in SDK references...
• 422b9a4 chore: update versions and lockfile [version bump]
• Additional commits viewable in compare view

[operon-ensemble-reviewer]

This review is outdated. See the latest ensemble review below.

Previous review

Ensemble Code Review

Verdict: comment

Summary: This is a Dependabot-driven production dependency bump of posthog-node (5.37.1 → 5.39.4) with no application code changes. The one substantive concern, flagged independently by all three reviewers and confirmed against the lockfile, is that the new posthog-node tightens its Node.js engine requirement beyond the project's declared support range. It doesn't block installs (pnpm doesn't enforce transitive engines), so this is a P1 alignment fix rather than a merge blocker.

Findings (1)

1. [P1] Engine constraint gap — package.json:24

Sources: Verifier, Pattern, Architect, Judge-verified

posthog-node@5.39.4 declares engines: { node: "^20.20.0 || >=22.22.0" } (confirmed in pnpm-lock.yaml:1646), but the project advertises broader support: root package.json:24 declares >=20.0.0 and packages/cli/package.json:56 likewise. This leaves a gap — Node 20.0.0–20.19.x and all of Node 21.x fall inside the project's stated support range but are incompatible with the new dependency.

pnpm does not enforce transitive engine constraints by default, so this won't fail installs or CI, which is why it's a P1 rather than a blocker. But users on an older Node 20 patch or Node 21 could hit runtime issues while believing they're on a supported version. Fix by aligning the project's engines.node (root + CLI) to >=20.20.0 (or ^20.20.0 || >=22.22.0) and verifying docs/CI match.

---

Suggestions (2)

• Update engines.node in both root package.json and packages/cli/package.json to >=20.20.0 to match posthog-node's new floor, and confirm CI's Node matrix and any documented support statements reflect the same minimum.
• The Architect noted potential behavioral changes across 5.37.x–5.39.x (retry semantics for /flags, feature-flag evaluation). Nothing in the diff proves a breaking change, but a quick skim of the changelog is worthwhile if the CLI relies on flag-gated behavior or event-delivery guarantees — no test changes required unless a relied-upon default shifted.

---

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

This review is outdated. See the latest ensemble review below.

Previous review

Ensemble Code Review

Verdict: comment

Summary: This is a Dependabot-driven production dependency bump of posthog-node (5.37.1 → 5.39.4) with no application code changes. All three reviewers independently flagged one substantive concern, confirmed against the lockfile: the new posthog-node tightens its Node.js engine requirement beyond the project's declared support range. pnpm doesn't enforce transitive engines, so this is a P1 alignment fix, not a merge blocker.

Findings (1)

1. [P1] Engine constraint gap — package.json:24

Sources: Verifier, Pattern, Architect, Judge-verified

posthog-node@5.39.4 declares engines: { node: "^20.20.0 || >=22.22.0" } (confirmed in pnpm-lock.yaml), but the project advertises broader support: root package.json:24 declares >=20.0.0 and packages/cli/package.json:56 declares >=20. This leaves a gap — Node 20.0.0–20.19.x and all of Node 21.x fall inside the project's stated support range but are incompatible with the new dependency.

pnpm does not enforce transitive engine constraints by default, so this won't fail installs or CI, which is why it's a P1 rather than a blocker. But users on an older Node 20 patch or Node 21 could hit runtime issues while believing they're on a supported version. Fix by aligning the project's engines.node (root + CLI) to >=20.20.0 (or ^20.20.0 || >=22.22.0) and verifying docs/CI match.

---

Suggestions (2)

• Align engines.node in both root package.json and packages/cli/package.json to at least >=20.20.0 to match posthog-node's new floor, and confirm CI's Node matrix and any documented support statements reflect the same minimum. (Alternatively, pin posthog-node to the last version compatible with the current Node support window.)
• Since posthog-node sits in the core telemetry/analytics path, consider adding a small smoke/integration test that initializes the client and performs a basic call (capture or flag fetch). This diff changes no app code, but such coverage would catch behavioral shifts (retry/flags semantics) in future bumps.

---

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

Ensemble Code Review

Verdict: comment

Summary: This is a Dependabot-driven production dependency bump of posthog-node (5.37.1 → 5.39.4) in packages/core, with no application code changes. All three reviewers independently converged on one substantive concern, confirmed against the lockfile and package manifests: the new posthog-node tightens its Node.js engine requirement beyond the project's declared support range. Since pnpm doesn't enforce transitive engines, this is a P1 alignment fix rather than a merge blocker.

Findings (1)

1. [P1] Engine constraint gap — package.json:24

Sources: Verifier, Pattern, Architect

posthog-node@5.39.4 declares engines: { node: "^20.20.0 || >=22.22.0" } (confirmed in pnpm-lock.yaml), but the project advertises broader support: root package.json:24 declares >=20.0.0 and packages/cli/package.json:56 declares >=20 (Verifier-confirmed against both files). This leaves a gap — Node 20.0.0–20.19.x and all of Node 21.x fall inside the project's stated support range but are incompatible with the new dependency.

pnpm does not enforce transitive engine constraints by default, so this won't fail installs or CI, which is why it's a P1 rather than a blocker. But users on an older Node 20 patch or Node 21 could hit runtime issues while believing they're on a supported version. Fix by aligning the project's engines.node (root + CLI) to >=20.20.0 (or ^20.20.0 || >=22.22.0 to mirror upstream), and verifying CI's Node matrix and any documented support statements match.

---

Suggestions (2)

• Align engines.node in both root package.json and packages/cli/package.json to at least >=20.20.0 to match posthog-node's new floor, and confirm CI's Node matrix and any documented support statements reflect the same minimum. (Alternatively, pin posthog-node to the last version compatible with the current Node support window.)
• Since posthog-node sits in the core telemetry/analytics path and this bump also updates @posthog/core and @posthog/types, consider adding or verifying at least one integration test exercising your core analytics flows (identify/capture/feature flags) to catch upstream behavioral changes (e.g. retry semantics on /flags, flag-evaluation changes) on future bumps.

---

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

Ensemble Code Review

Verdict: comment

Summary: This is a Dependabot-driven production dependency bump of posthog-node (5.37.1 → 5.40.0) with no application code changes. All three reviewers again converged on a single substantive concern, grounded against the lockfile: the new posthog-node tightens its Node.js engine requirement beyond the project's declared support range. pnpm doesn't enforce transitive engines, so this is a non-blocking P1 alignment fix that has now carried forward across multiple bumps without resolution.

Findings (1)

1. [P1] Engine constraint gap — package.json:24

Sources: Verifier, Pattern, Architect

posthog-node@5.40.0 declares engines: { node: "^20.20.0 || >=22.22.0" } (confirmed in the lockfile diff), but the project advertises broader support: root package.json:24 declares >=20.0.0 and packages/cli/package.json:56 declares >=20. This leaves a gap — Node 20.0.0–20.19.x and all of Node 21.x fall inside the project's stated support range but are incompatible with the new dependency.

pnpm does not enforce transitive engine constraints by default, so this won't fail installs or CI, which is why it's a P1 rather than a blocker. But users on an older Node 20 patch or Node 21 could hit runtime issues while believing they're on a supported version. Fix by aligning the project's engines.node (root + CLI) to >=20.20.0 (or ^20.20.0 || >=22.22.0 to mirror upstream) and verifying CI's Node matrix and any documented support statements match — or pin posthog-node to the last version compatible with the current support window.

Note: this finding has now recurred across three prior review rounds (5.39.4 → 5.40.0) without a response. Consider resolving it in this PR or tracking it in a dedicated follow-up so it stops re-surfacing on each Dependabot bump.

---

Suggestions (2)

• Align engines.node in both root package.json and packages/cli/package.json to at least >=20.20.0 (or mirror ^20.20.0 || >=22.22.0), and confirm CI's Node matrix and any documented support statements reflect the same minimum.
• If you intend to keep broader Node support (Node 21.x or earlier 20.x patches), instead pin posthog-node to the last version compatible with the current support window and have Dependabot ignore engine-tightening bumps until the support matrix is intentionally raised.

---

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

Ensemble Code Review

Verdict: comment

Summary: This is a Dependabot-driven production dependency bump of posthog-node (5.37.1 → 5.46.1) with no application code changes. All three reviewers again converged on the single recurring concern, Verifier-grounded against the lockfile and both manifests: the new posthog-node requires a narrower Node.js engine range than the project advertises. pnpm doesn't enforce transitive engines, so this is a non-blocking P1 alignment fix — but it has now carried across five review rounds without a response.

Findings (1)

1. [P1] Engine constraint gap (recurring, unaddressed) — package.json:24

Sources: Verifier, Pattern, Architect

posthog-node@5.46.1 declares engines: { node: "^20.20.0 || >=22.22.0" } (Verifier-confirmed at pnpm-lock.yaml:1646), but the project advertises broader support: root package.json:24 declares >=20.0.0 and packages/cli/package.json:56 declares >=20. This leaves a gap — Node 20.0.0–20.19.x and all of Node 21.x fall inside the project's stated support range but outside the dependency's.

pnpm does not enforce transitive engine constraints by default, so this won't fail installs or CI, which is why it's a P1 rather than a blocker. But users on an older Node 20 patch or Node 21 could hit runtime issues while believing they're on a supported version. Fix by aligning engines.node in both manifests (root + CLI) to at least >=20.20.0 (or ^20.20.0 || >=22.22.0 to mirror upstream), and confirm CI's Node matrix and any documented support statements match — or pin posthog-node to the last version compatible with the current support window.

Note: this finding has now recurred across five review rounds (5.39.4 → 5.46.1) without a response. Consider resolving it here or tracking it in a dedicated follow-up so it stops re-surfacing on every Dependabot bump.

---

Suggestions (2)

• Align engines.node in both root package.json and packages/cli/package.json to at least >=20.20.0 to match posthog-node's new floor, and confirm CI's Node matrix and any documented support statements reflect the same minimum. Alternatively, pin posthog-node to the last version compatible with the current >=20.0.0 promise.
• Since posthog-node sits in the core telemetry/analytics path and this is a non-trivial jump (5.37.x → 5.46.x plus updated @posthog/core/@posthog/types), consider adding a smoke/integration test around analytics/feature-flag usage so future dependency bumps get early warning of behavioral regressions.

---

Verified clean

• Diff is a pure dependency version bump — no application code changes (Verifier).
• Lockfile engine constraint for posthog-node@5.46.1 confirmed as ^20.20.0 || >=22.22.0 at pnpm-lock.yaml:1646 (Verifier).
• Root package.json:24 (>=20.0.0) and packages/cli/package.json:56 (>=20) confirmed unchanged (Verifier).
• No new API surface, config contracts, or breaking changes introduced (Architect).
• No new security or performance smells in application code (Pattern Matcher).

---

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

🔍 Ensemble Code Review — 1 inline finding(s); verdict comment. Full summary in the comment below.

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

Ensemble Code Review

Verdict: comment

Summary: This is a Dependabot-driven production dependency bump of posthog-node (5.37.1 → 5.46.1) in packages/core with no application code changes. All three reviewers again converged on the single recurring concern, Verifier-grounded against the lockfile and both manifests: the new posthog-node requires a narrower Node.js engine range than the project advertises. pnpm doesn't enforce transitive engines, so this is a non-blocking P1 alignment fix — but it has now carried across multiple review rounds without a response.

Findings (1)

1. [P1] Engine constraint gap (recurring, unaddressed) — package.json:24

Sources: Verifier, Pattern, Architect

posthog-node@5.46.1 declares engines: { node: "^20.20.0 || >=22.22.0" } (Verifier-confirmed at the posthog-node@5.46.1 entry in the pnpm-lock.yaml packages section), but the project advertises broader support: root package.json:24 declares >=20.0.0 and packages/cli/package.json:56 declares >=20. This leaves a gap — Node 20.0.0–20.19.x and all of Node 21.x fall inside the project's stated support range but outside the dependency's.

pnpm does not enforce transitive engine constraints by default, so this won't fail installs or CI, which is why it's a P1 rather than a blocker. But users on an older Node 20 patch or Node 21 could hit runtime issues while believing they're on a supported version. Fix by aligning engines.node in both manifests (root + CLI) to at least >=20.20.0 (or ^20.20.0 || >=22.22.0 to mirror upstream), and confirm CI's Node matrix and any documented support statements match — or pin posthog-node to the last version compatible with the current support window.

Note: this finding has now recurred across five prior review rounds (5.39.4 → 5.46.1) without a response. Consider resolving it here or tracking it in a dedicated follow-up so it stops re-surfacing on every Dependabot bump.

---

Suggestions (2)

• Track the engine-alignment fix in a dedicated issue/PR so it stops resurfacing on every Dependabot bump — either tighten declared engines.node (root + CLI + CI matrix + docs) or cap posthog-node at the last release compatible with the current Node support window.
• Since posthog-node sits in the telemetry path, consider a high-level smoke/integration test that exercises telemetry initialization on officially supported Node versions, to catch future upstream engine or behavior changes that unit/type checks would miss.

---

Verified clean

• No application code changes — diff is limited to packages/core/package.json and the corresponding pnpm-lock.yaml update (Verifier).
• posthog-node@5.46.1 engine constraint confirmed directly in the lockfile packages section (Verifier).
• Root package.json:24 (>=20.0.0) and packages/cli/package.json:56 (>=20) confirmed unchanged (Verifier).
• No new security, performance, or idiomatic-correctness risks introduced by the bump itself (Pattern Matcher).
• No direct API/contract changes in project code (Architect).

---

Generated by Operon Ensemble Code Review.

[operon-ensemble-reviewer]

🔍 Ensemble Code Review — 1 inline finding(s); verdict comment. Full summary in the a separate comment.

Generated by Operon Ensemble Code Review.