feat(deep-links): Use posthog-code-dev scheme in dev builds

[Twixes]

Problem

In development builds, the app was skipping deep link protocol registration entirely to avoid stealing the posthog-code:// scheme from a production install. This made it impossible to test deep linking as a dev.

Changes

Introducing a posthog-code-dev URL scheme for development builds only, defined via getDeeplinkProtocol(isDevBuild). This function returns posthog-code-dev in dev and posthog-code in production.

1. Dev builds now register and handle posthog-code-dev:// instead of skipping registration altogether.
2. Production builds continue to register posthog-code:// along with the legacy twig:// and array:// schemes.

How did you test this?

Updated and added unit tests in service.test.ts covering:

• registerProtocol registers only posthog-code-dev in dev and all three schemes in production.
• handleUrl accepts posthog-code-dev:// in dev and rejects posthog-code://, and vice versa in production.
• getProtocol returns the correct scheme per build.

[Twixes]

• feat(deep-links): Use posthog-code-dev scheme in dev builds #1780 👈 (View in Graphite)
• feat(inbox): Allow sharing Inbox reports with posthog-code://inbox/ URL #1757
• main

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

[greptile-apps]

Comments Outside Diff (1)

1. apps/code/src/main/services/deep-link/service.test.ts, line 44-79 (link)

   Prefer parameterised tests

   The registerProtocol describe block has two independent cases (production vs development) that are a natural fit for it.each. The primary protocol by build and getProtocol describes share the same pattern. Consolidating them would reduce duplication and make adding future schemes a one-line change, in line with the project's preference for parameterised tests.

   it.each([
     { isDev: "false", expectedSchemes: ["posthog-code", "twig", "array"] },
     { isDev: "true", expectedSchemes: ["posthog-code-dev"] },
   ])(
     "registers $expectedSchemes when POSTHOG_CODE_IS_DEV=$isDev",
     ({ isDev, expectedSchemes }) => {
       process.env.POSTHOG_CODE_IS_DEV = isDev;
       service.registerProtocol();
       for (const scheme of expectedSchemes) {
         expect(mockAppLifecycle.registerDeepLinkScheme).toHaveBeenCalledWith(scheme);
       }
       expect(mockAppLifecycle.registerDeepLinkScheme).toHaveBeenCalledTimes(expectedSchemes.length);
     },
   );

   The same pattern applies to the primary protocol by build block (lines 242-271) and getProtocol block (lines 274-284).

   Context Used: Do not attempt to comment on incorrect alphabetica... (source)

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/code/src/main/services/deep-link/service.test.ts
   Line: 44-79
   
   Comment:
   **Prefer parameterised tests**
   
   The `registerProtocol` describe block has two independent cases (production vs development) that are a natural fit for `it.each`. The `primary protocol by build` and `getProtocol` describes share the same pattern. Consolidating them would reduce duplication and make adding future schemes a one-line change, in line with the project's preference for parameterised tests.
   
   ```ts
   it.each([
     { isDev: "false", expectedSchemes: ["posthog-code", "twig", "array"] },
     { isDev: "true", expectedSchemes: ["posthog-code-dev"] },
   ])(
     "registers $expectedSchemes when POSTHOG_CODE_IS_DEV=$isDev",
     ({ isDev, expectedSchemes }) => {
       process.env.POSTHOG_CODE_IS_DEV = isDev;
       service.registerProtocol();
       for (const scheme of expectedSchemes) {
         expect(mockAppLifecycle.registerDeepLinkScheme).toHaveBeenCalledWith(scheme);
       }
       expect(mockAppLifecycle.registerDeepLinkScheme).toHaveBeenCalledTimes(expectedSchemes.length);
     },
   );
   ```
   
   The same pattern applies to the `primary protocol by build` block (lines 242-271) and `getProtocol` block (lines 274-284).
   
   **Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Prompt To Fix All With AI

This is a comment left during a code review.
Path: apps/code/src/main/services/deep-link/service.test.ts
Line: 44-79

Comment:
**Prefer parameterised tests**

The `registerProtocol` describe block has two independent cases (production vs development) that are a natural fit for `it.each`. The `primary protocol by build` and `getProtocol` describes share the same pattern. Consolidating them would reduce duplication and make adding future schemes a one-line change, in line with the project's preference for parameterised tests.

```ts
it.each([
  { isDev: "false", expectedSchemes: ["posthog-code", "twig", "array"] },
  { isDev: "true", expectedSchemes: ["posthog-code-dev"] },
])(
  "registers $expectedSchemes when POSTHOG_CODE_IS_DEV=$isDev",
  ({ isDev, expectedSchemes }) => {
    process.env.POSTHOG_CODE_IS_DEV = isDev;
    service.registerProtocol();
    for (const scheme of expectedSchemes) {
      expect(mockAppLifecycle.registerDeepLinkScheme).toHaveBeenCalledWith(scheme);
    }
    expect(mockAppLifecycle.registerDeepLinkScheme).toHaveBeenCalledTimes(expectedSchemes.length);
  },
);
```

The same pattern applies to the `primary protocol by build` block (lines 242-271) and `getProtocol` block (lines 274-284).

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "feat(deep-links): Use `posthog-code-dev`..." | Re-trigger Greptile}

[adboio]

@ryans-posthog probably not(?) but maybe related to the issues you were telling me about yesterday

[graphite-app]

Merge activity

• Apr 22, 7:53 AM UTC: This pull request can not be added to the Graphite merge queue. Please try rebasing and resubmitting to merge when ready.
• Apr 22, 7:53 AM UTC: Graphite disabled "merge when ready" on this PR due to: a merge conflict with the target branch; resolve the conflict and try again..
• Apr 22, 8:03 AM UTC: @Twixes merged this pull request with Graphite.