Skip to content
This repository has been archived by the owner on Sep 8, 2023. It is now read-only.

refactor: remove overly strict context types #108

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

treyp
Copy link

@treyp treyp commented Apr 13, 2023

Description

The TypeScript types for the context option added in #61 are overly strict. The context option is merely passed through to plugins. This library makes no use of it directly, so the typings do not need to be strict.

Additionally, the overrides structure is currently set to any non-nullable value, so some types for that are added here.

Additionally, previously missed options for the client config have been added to that type.

Motivation and Context

Consumers of this library who use context and TypeScript are forced to either unnecessarily conform to the types defined here (which depend on hapi, pino, and a proprietary auth structure) or disable TypeScript by other means.

How Has This Been Tested?

Used the new definitions in a private project that uses service-client and TypeScript compilation was still successful.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • I have updated the typings as necessary.

Other minor type changes: add types for overrides, fix broken payload type

BREAKING CHANGE: The TypeScript types ServiceRequest and ServiceContext have been removed as service-client is not concerned with the shape of the context passed to it. Use types relevant to the context that you provide instead.
@@ -37,23 +37,6 @@ export type ServiceClientOptions = {
timeout?: number;
};

export interface ServiceRequest {
Copy link
Author

Choose a reason for hiding this comment

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

This library has no need for any specificity in this type, used for the context option, which is passed through to plugins without being accessed by this library

@@ -37,23 +37,6 @@ export type ServiceClientOptions = {
timeout?: number;
};

export interface ServiceRequest {
headers: Headers;
logger: Logger;
Copy link
Author

Choose a reason for hiding this comment

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

This would require use of pino, which is not a requirement to use service-client

isAuthenticated: boolean;
credentials: {
apiToken: string;
principalToken: string;
Copy link
Author

Choose a reason for hiding this comment

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

This is a proprietary auth credential structure

}

export type ServiceContext = {
dataSources: {[serviceClient: string]: ClientInstance};
Copy link
Author

Choose a reason for hiding this comment

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

This would require use of graphql-component which is not a requirement to use this library

};
}

export type ServiceContext = {
Copy link
Author

Choose a reason for hiding this comment

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

This type is not used anywhere

};
export type ServiceConfig = {
protocol?: string;
hostname?: string;
Copy link
Author

Choose a reason for hiding this comment

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

Removed comments and added types for options that were previously missed like hostname

@shellbj shellbj self-assigned this Apr 18, 2023
@shellbj shellbj requested review from shellbj and kisaiev April 18, 2023 14:44
@shellbj shellbj added enhancement New feature or request hold labels Apr 25, 2023
@shellbj
Copy link
Contributor

shellbj commented Apr 25, 2023

Thanks for your PR. This will be scheduled for a larger release cycle, tentatively targeting early Q3, due to the breaking nature of this change.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request hold
Development

Successfully merging this pull request may close these issues.

2 participants