[DIT-11523] Add support for meta flag

[marla-hoggard]

Overview

Adds support for the -m or --meta flag, which allows users to pass custom metadata along with a CLI command. We use this internally to identify requests that come from our github action, which dispatches the following command pull -m githubActionRequest: true.

If we get this particular piece of metadata, we want to place it in the request header, so that our main application will set req.application = "github_action" for segment events. This is very different than the legacy implementation, which would indiscriminately pass all metadata along as req.query. Now that we have strong zod typing for our requests, it didn't seem like a good idea to add random, user-defined values to the query object, so only this one value is actually used for anything. Any other metadata is currently processed but ultimately ignored.

I do not intend to document this flag publicly, in the README or dev docs, since it's currently only used internally by us in the github action implementation.

Context

https://linear.app/dittowords/issue/DIT-11523/legacy-github-action-not-supported-in-cli-v500

Test Plan

Main app setup

• To test this end-to-end, pull down marla/dit-11523-github-action-segment branch of the main ditto-app repo, until https://github.com/dittowords/ditto-app/pull/7869 is merged.
• To see what data we're passing to segment, I added the following on line 245 of shared/ditto-events/backend.ts

if (target.type === "segment") {
  console.log(`Emitting Ditto event "${dittoEvent.name}" to Segment`, result);
}

• Start the public api on that branch with yarn start:api

CLI Testing

• Run yarn start pull
  • The pull should complete successfully
  • The segment event in the main app should have cli as the application property
• Run yarn start pull -m githubActionRequest:true
  • The pull should complete successfully
  • The segment event in the main app should have github_action as the application property
• Run yarn start pull --meta githubActionRequest:true
  • The pull should complete successfully
  • The segment event in the main app should have github_action as the application property
• Run yarn start pull -m something:else
  • The pull should complete successfully
  • The segment event in the main app should have cli as the application property
  • The extra metadata should be consumed safely but otherwise ignored

[marla-hoggard]

I don't love that we have to manually pass meta into each one of these methods. If someone makes a new method, there's nothing to enforce that they won't forget to include the meta argument.

I added meta into the formatter class definition, but this isn't a class method, so it can't be pulled automatically without a bigger refactor of some kind.

Any recommendations for a better, future-proof pattern? I would love it if there were a more global context that we could use to pass meta into getHttpClient in one place and then these could go back to importing the httpClient that that getHttpClient returned.

[poteat]

Yeah I would also like that sort of holy grail

There might be a form of using satisifies that could add a bit of safety here?

[poteat]

Works great!