Skip to content

feat: add client and client version to request headers#412

Merged
Swiftwork merged 4 commits intomainfrom
feat/add-client-and-client-version
May 21, 2025
Merged

feat: add client and client version to request headers#412
Swiftwork merged 4 commits intomainfrom
feat/add-client-and-client-version

Conversation

@Swiftwork
Copy link
Contributor

No description provided.

@Swiftwork Swiftwork requested review from Copilot and roncohen May 20, 2025 12:01
@Swiftwork Swiftwork self-assigned this May 20, 2025
@Swiftwork Swiftwork added the enhancement New feature or request label May 20, 2025
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR adds client and client version information to the request headers to support enhanced tracking and versioning. Key changes include:

  • Adding "X-Client" and "X-Client-Version" headers in the auth request (auth.ts).
  • Reading the client version from package.json and exposing it via a getter in the configuration store (config.ts).
  • Bumping the CLI package version (package.json).

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
packages/cli/utils/auth.ts Adds client and client version headers to outgoing requests.
packages/cli/stores/config.ts Reads and stores the client version from package.json.
packages/cli/package.json Increments the version to reflect the new changes.

@Swiftwork Swiftwork added this pull request to the merge queue May 20, 2025
@roncohen
Copy link
Contributor

The SDKs are using bucket-sdk-version. Maybe it makes sense for the CLI as well?

@roncohen
Copy link
Contributor

removing from queue to ensure we get this discussion in ^^

@roncohen roncohen removed this pull request from the merge queue due to a manual request May 20, 2025
@Swiftwork
Copy link
Contributor Author

removing from queue to ensure we get this discussion in ^^

Good.

The SDKs are using bucket-sdk-version. Maybe it makes sense for the CLI as well?

Hmm, good point.

@Swiftwork
Copy link
Contributor Author

The SDKs are using bucket-sdk-version. Maybe it makes sense for the CLI as well?

Out of curiosity, is there a reason we didn't go for an X- header? And should I use a similar bucket-sdk-client header alongside it @roncohen ?

@roncohen
Copy link
Contributor

AFAIR we investigated and found that there was no additional benefit of prefixing "x-". E.g. the pattern was recommended against as outdated. But I admit it's all from hazy memory.

@Swiftwork
Copy link
Contributor Author

AFAIR we investigated and found that there was no additional benefit of prefixing "x-". E.g. the pattern was recommended against as outdated. But I admit it's all from hazy memory.

Fair enough. I'll update the code to use bucket-sdk-version and introduce bucket-sdk-client. I think I must update the web to accept this new header first so not reject requests.

@roncohen
Copy link
Contributor

I'll update the code to use bucket-sdk-version and introduce bucket-sdk-client

We've sending both in the same header following this pattern today: client/version. See https://github.com/bucketco/bucket-javascript-sdk/blob/main/packages/browser-sdk/src/config.ts#L9 for an example.

@Swiftwork
Copy link
Contributor Author

I'll update the code to use bucket-sdk-version and introduce bucket-sdk-client

We've sending both in the same header following this pattern today: client/version. See https://github.com/bucketco/bucket-javascript-sdk/blob/main/packages/browser-sdk/src/config.ts#L9 for an example.

Done :)

@roncohen
Copy link
Contributor

thanks @Swiftwork. I just realized the CLI is of course talking to the REST API, not the front facing API, so there's no actual requirement to follow what the SDKs do - apologies for the turkey chase. I'm OK to go with bucket-sdk-client now since it'll at least be consistent with the front facing API.

- Introduced a `moduleRoot` constant to simplify path calculations for the schema and package.json files.
- Updated the `createValidator` method to use `moduleRoot` for resolving the schema path and loading the client version from package.json, enhancing code clarity and maintainability.
- Removed redundant code related to package.json path handling, improving overall efficiency.
@Swiftwork Swiftwork requested a review from roncohen May 21, 2025 10:06
@Swiftwork Swiftwork added this pull request to the merge queue May 21, 2025
Merged via the queue into main with commit a97d762 May 21, 2025
6 checks passed
@Swiftwork Swiftwork deleted the feat/add-client-and-client-version branch May 21, 2025 13:47
Comment on lines +96 to +103
const moduleMetadata = await readFile(
join(moduleRoot, "package.json"),
"utf-8",
);
const moduleMetadataParsed = parseJSON(moduleMetadata) as unknown as {
version: string;
};
this.clientVersion = moduleMetadataParsed.version;
Copy link
Contributor

Choose a reason for hiding this comment

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

this is probably fine, but as a point of reference this is what the SDKs do: https://github.com/bucketco/bucket-javascript-sdk/blob/main/packages/browser-sdk/src/config.ts#L1

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can't unfortunately do that without getting the "importing json is experimental warning" because the package uses type "module"

Copy link
Contributor

Choose a reason for hiding this comment

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

gotcha 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants