Skip to content

feat: refactor + improve stability#1585

Open
k11kirky wants to merge 1 commit into04-08-feat_improve_tests_fix_cache_and_fix_packagefrom
04-09-feat_refactor_improve_stability
Open

feat: refactor + improve stability#1585
k11kirky wants to merge 1 commit into04-08-feat_improve_tests_fix_cache_and_fix_packagefrom
04-09-feat_refactor_improve_stability

Conversation

@k11kirky
Copy link
Copy Markdown
Contributor

@k11kirky k11kirky commented Apr 9, 2026

TLDR

Problem

Changes

Copy link
Copy Markdown
Contributor Author

k11kirky commented Apr 9, 2026

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

@k11kirky k11kirky marked this pull request as ready for review April 9, 2026 12:22
@k11kirky k11kirky force-pushed the 04-08-feat_improve_tests_fix_cache_and_fix_package branch from 8ec3c95 to b27f7d7 Compare April 9, 2026 12:34
@k11kirky k11kirky force-pushed the 04-09-feat_refactor_improve_stability branch from b634893 to 7e80e97 Compare April 9, 2026 12:34
@k11kirky k11kirky mentioned this pull request Apr 9, 2026
FeatureFlag,
} from "./types.js";

export class PostHogApi {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this something we can potentially share w/ the vs code extension too? not sure how valuable it is to share since just a wrapper on the API but wanna try to keep things tidy if/when we make the swap

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah definitely — it's a thin wrapper around the PostHog REST API (flags, experiments, event definitions, event stats via HogQL). Same PostHogApi class could be shared with the VS Code extension. It'll ship as part of @posthog/enricher.

Comment on lines +35 to +41
enriched.enrichedFlags;
// [{ flagKey: "new-checkout", flagType: "boolean", staleness: "fully_rolled_out",
// rollout: 100, experiment: { name: "Checkout v2", ... }, ... }]

// Events with definition, volume, unique users
enriched.enrichedEvents;
// [{ eventName: "purchase", verified: true, lastSeenAt: "2025-04-01",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[the tiniest nitpick ever lol feel free to ignore]

i would prefer enriched.flags and enriched.events on this interface 🙈

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already addressed in the simplify PR (#1589) — the README and EnrichedResult class both use enriched.flags and enriched.events 👍

// { type: "flag", name: "new-checkout", flagType: "boolean", staleness: "fully_rolled_out", ... }]

// Source code with inline annotation comments
enriched.toComments();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is fire

parts.push(`Experiment: "${flag.experiment.name}" (${status})`);
}
if (flag.staleness) {
parts.push(`STALE (${flag.staleness})`);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lazy-web: what are the possible values for flag.staleness ?

just wondering if it provides anything significantly different from the text "STALE", and if not, perhaps not work feeding to the LLM

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Values are: "fully_rolled_out" | "inactive" | "not_in_posthog" | "experiment_complete"

More granular than just "STALE" — the formatter shows it as STALE (fully_rolled_out) etc. Useful context for both agents and the diff viewer since you can distinguish between 'this flag doesn't exist in PostHog' vs 'this experiment is done' vs 'this is 100% rolled out for 30+ days'.

Comment on lines +59 to +60
// One comment per original source line — if multiple detections share a line,
// only the first (by sort order) gets an annotation to keep output readable.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thoughts on removing this restriction?

probably an edge case (i'd be impressed to see a single line of code with a large number of posthog events/flags 😛), but might be preferable to display everything, esp if the target audience is an agent?

(context for example: in the diff viewer, i'd like to add these things as token hovers, so we'd have full control over the UX and there's no issue with multiple things coming from a single src line)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call — removed the per-line limit in the simplify PR (#1589). The current formatComments() inserts a comment for every item regardless. Agree this makes more sense especially for the token hover use case in the diff viewer.

@k11kirky k11kirky force-pushed the 04-09-feat_refactor_improve_stability branch from 7e80e97 to bda15b3 Compare April 11, 2026 13:11
@k11kirky k11kirky force-pushed the 04-08-feat_improve_tests_fix_cache_and_fix_package branch from b27f7d7 to 8448ed6 Compare April 11, 2026 13:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants