chore(deps): upgrade posthog-node 4 -> 5 in daemon#2309
Conversation
Breaking changes addressed: - posthog-node v5 replaces axios/follow-redirects/proxy-from-env with @posthog/core (native fetch); no call-site changes required β the PostHog constructor signature, capture(), identify(), groupIdentify(), on(), and shutdown() surface used by apps/daemon/src/analytics.ts is stable across the major boundary. - shutdown() is still async in @posthog/core (PostHogCoreStateless base class); the IPostHog interface in posthog-node types it as void but the inherited Promise<void> from @posthog/core keeps await client.shutdown() correct at runtime. - protobufjs resolved version: 7.5.7 (pre-existing; posthog-node v5 does not pull in @opentelemetry, so no change to protobufjs from this bump).
lefarcen
added
size/S
PerishCode
left a comment
PerishCode
left a comment
There was a problem hiding this comment.
@neogenix Thanks for picking this one up β a tight, well-scoped bump.
What I verified on 308a1c6b:
- Only
apps/daemon/package.jsonandpnpm-lock.yamlchange;posthog-node4.18.0 β 5.34.6 with@posthog/[email protected]already present in the lockfile viaposthog-js, so the v5 client just becomes a second consumer rather than a brand-new top-level package. - The dropped transitives (
axios,follow-redirects,proxy-from-env) are no longer referenced anywhere in the lockfile after the bump β a genuine surface-area reduction, and removingfollow-redirectsis a real win given its CVE history. apps/daemon/src/analytics.tsstill uses the v5-stable surface βnew PostHog(key, { host, flushAt, flushInterval }),client.on?.('error', ...)(already optional-chained, so safe even if it were dropped),client.capture({ distinctId, event, properties }), andawait client.shutdown()β so no call-site edits are needed.- v5's engine constraint
^20.20.0 || >=22.22.0is comfortably satisfied by the repo's pinnednode: "~24"in the rootpackage.json#engines. - Validation evidence in the PR body (lockfile resolve, daemon typecheck, daemon test suite,
pnpm guard, rootpnpm typecheck) covers exactly the surfaces this bump touches.
Nice clean upgrade β appreciate the careful framing of the v5 API stability in the PR body so reviewers didn't have to re-derive it.
π Powered by Looper Β· runner=reviewer Β· agent=claude-code Β· An autonomous AI dev team for your GitHub repos.
π π‘ You just leveled up to Giotto
π Your contributions are sending a clear signal across the network: you care about making Open Design better. Keep transmitting. π Thanks for helping Open Design move forward. Keep building in the open. π π Rank #46 among 96 contributors |
|
Hi @neogenix! Your first Open Design PR has been merged! Huge thanks for jumping in and improving the project! You contributed: Merged PR: #2309 chore(deps): upgrade posthog-node 4 -> 5 in daemon That is a real contribution to the daemon/tooling side of Open Design, and we would love to help you keep the momentum going! For your next contribution, we picked two issues that look like a good follow-up:
This is a focused tooling/chore task, which matches the kind of maintenance work you just helped with!
This is a good first issue with a clear user-facing bug, and it should be a nice next step if you want something smaller and product-visible! If one of these looks interesting, feel free to comment /claim on the issue and we will help you get started! Once your second PR gets merged, you will move into our Continuous Contributor tier. We are also starting to highlight repeat contributors more actively in the community, so this is a great time to keep going! Thanks again for the first PR, and welcome to the Open Design contributor community! The Open Design team P.S. We hang out in Discord β come say hi: https://discord.gg/3C6EWXbdQQ |
5 participants
Why
posthog-node 4.18.0 is a major version behind the current 5.x line. v5 restructures the library around a shared
@posthog/corepackage and dropsaxiosin favor of nativefetchβ reducing the transitive closure by three packages (axios,follow-redirects,proxy-from-env).follow-redirectsin particular has a history of CVEs; removing it entirely is a net security improvement.Note: open PR #2285 (
feat/analytics-2.0) is a PostHog event schema change, not an SDK version change β no conflict.What users will see
No user-visible change. Analytics continue to emit exactly as before.
Surface area
Screenshots
N/A
Bug fix verification
N/A β this is a dependency upgrade, not a bug fix.
Validation
pnpm installβ lockfile updated; posthog-node 5.34.6 resolved with @posthog/core 1.29.5pnpm --filter @open-design/daemon typecheckβ passed (exit 0)pnpm --filter @open-design/daemon testβ 240 test files passed, 2867 tests passed, 1 skipped, 4 todopnpm guardβ passedpnpm typecheckβ passed (exit 0, all workspace packages)@opentelemetry, so no change to protobufjs from this bump)Breaking changes addressed
posthog-node v5 replaces the
axios-based HTTP transport with@posthog/core(nativefetch). The public API surface used byapps/daemon/src/analytics.tsis stable across the major boundary:PostHogconstructor: unchanged (new PostHog(key, { host, flushAt, flushInterval }))client.capture({ distinctId, event, properties }): unchangedclient.on('error', cb): unchangedclient.shutdown(): still async at runtime via@posthog/corebase class (PostHogCoreStateless.shutdown()returnsPromise<void>); theIPostHoginterface in posthog-node types it asvoidbut TypeScript compiles cleanly since the concrete implementation satisfies the stricter type from the base classNo call-site changes were required in
apps/daemon/src/analytics.ts.