PostHog / posthog

πŸ¦” PostHog provides open-source product analytics, session recording, feature flagging and A/B testing that you can self-host.
https://posthog.com
Other
21.18k stars 1.25k forks source link

Feature request: Full typescript support for React & Node packages #22623

Open axelcedercreutz opened 4 months ago

axelcedercreutz commented 4 months ago

Feature request

Is your feature request related to a problem?

Currently, when using the posthog-js or posthog-node -packages, there's no way for us to know if a specific feature flag key/value is correctly spelled. This can lead to unwanted consequences due to typos and create friction in the development process as developers have to ensure manually.

Describe the solution you'd like

We'd love to have a way to have a script for generating the feature flag key/value pairs based on a project. It can be either a CLI tool (like e.g. Supabase does) or even just an endpoint that returns the types in some deconstructable manner.

Describe alternatives you've considered

Haven't figured out any other ways than the current manual process of checking the values from Posthog and replicating the types locally.

Additional context

We have a multi-project setup for two different products + 2 environments for each product. The lack of environment support makes things unfortunately even harder πŸ˜…

Debug info

- [x] PostHog Cloud, Debug information: [please copy/paste from https://us.posthog.com/settings/project-details#variables]

Session: https://us.posthog.com/project/sTMFPsFhdP1Ssg/replay/018fdcb2-8561-78c2-9c95-143e67b4e91a?t=2793 
Admin: http://go/adminOrgEU/0189e305-f393-0000-14dd-0eb1166f3c9f (Project: 23585)
Sentry: http://go/sentryEU/23585
miguelhrocha commented 4 months ago

Hey @axelcedercreutz,

I started to think of a solution for this, as I recently worked on extending the posthog-java project with feature flags support. I'd like to know what would be the best API from a node developer perspective:

  1. Create a custom type for all the feature flags in a project:

    type Flag = 'node-flag-1' | 'node-flag-2' | 'node-flag-3';
  2. Create a FeatureFlag type, where the key would be an enum:

    
    enum Flag {
    NEW_FEATURE = 'node-new-feature',
    EXPERIMENT = 'node-experiment',
    EXPERIMENT_WITH_GROUPS = 'node-experiment-with-groups',
    EXPERIMENT_WITH_MULTIVARIATE = 'node-experiment-with-multivariate',
    }

enum FlagVariants { VARIANT_A = 'node-variant-a', VARIANT_B = 'node-variant-b', VARIANT_C = 'node-variant-c', }

type FeatureFlag = { key: Flag rollout_percentage: number groups: Array<{ properties: Array<{ key: string value: string operator: string }> }> multivariate: { variants: Array<{ key: FlagVariants rollout_percentage: number }> } }



My heart tells me is option number 2, or another option I haven't thought of πŸ˜…

Let me know your thoughts!
slshults commented 4 months ago

Hey @axelcedercreutz ,

Thanks for adding the feature request!

For retrieving a list of feature flag keys and values for a project, have you already checked out the feature flag endpoints for our API?

axelcedercreutz commented 3 months ago

@miguelhrocha awesome stuff! Personally I'd also lean towards option 2 with a general FeatureFlag-type that connects the key and values. Not sure how required e.g. the rollout information is (atm at least we don't have a need for that), so a simpler version could be something like

type FeatureFlag = 'node-new-feature' |Β 'node-experiment' |Β 'node-experiment-with-groups' |Β  'node-experiment-with-multivariate'

type NodeNewFeature = boolean;

type NodeExperiment = 'control' | 'new';

interface NodeExperimentWithGroups {
  group1: boolean;
  group2: 'control' | 'new';
}

interface NodeExperimentWithMultivariate {
  foo: 'value';
  bar: 'other value';
}

interface FeatureFlags: Record<FeatureFlag, FeatureDefinition>  {
  'node-new-feature': NodeNewFeature;
  'node-experiment': NodeExperiment;
  'node-experiment-with-groups': NodeExperimentWithGroups;
  'node-experiment-with-multivariate': NodeExperimentWithMultivariate;
}

Not yet sure how to define the suggested FeatureDefinition yet, but should be doable I think.

@slshults thanks for adding the link to the API documentation. I think writing the script based on the API could definitely be an option for us πŸ‘ However, the feature request is more because I believe that there could be a way supported by Posthog to do the same 😊