-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: better typing for metadata #2234
feat!: better typing for metadata #2234
Conversation
aa6809e
to
b5a36a0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a question on if this is a breaking change; I think so, and trying to understand how Sameena's concerns were concluded. I'm still reviewing the PR so just an initial comment.
projectNumber?: string; | ||
team?: 'editors' | 'owners' | 'viewers'; | ||
}; | ||
role?: 'OWNER' | 'READER' | 'WRITER' | 'FULL_CONTROL'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this strict typing in that if new fields are added in the API the node.js client will need to be updated as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/googleapis/nodejs-storage/pull/2234/files#diff-747d768492a54441f1682714c15429c572d74c031145c71672dec819ff94fbbbR109 this would act as a catch all for anything new so that it flows through without us having to make a change. However, we would obviously want to add anything new to the appropriate metadata interface to continue to support up to date typings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the unknown
too - encourages customers to validate it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great change - customers are gonna love it (including myself).
projectNumber?: string; | ||
team?: 'editors' | 'owners' | 'viewers'; | ||
}; | ||
role?: 'OWNER' | 'READER' | 'WRITER' | 'FULL_CONTROL'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the unknown
too - encourages customers to validate it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a few comments; the types looked appropriate from my review and more wondering about the use of unknown
export interface GetFilesCallback { | ||
( | ||
err: Error | null, | ||
files?: File[], | ||
nextQuery?: {}, | ||
apiResponse?: Metadata | ||
apiResponse?: unknown |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there more guidance on when to use unknown?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is some docs.
The reason I had to go with unknown is sort of twofold, first previously Metadata
was defined as any
and was being used to represent ACTUAL metadata as well as a raw API response. Ideally we would have a well defined type for an API response but seeing as we are still using 2 HTTP libraries that is a bit more difficult currently.
} | ||
|
||
export interface GetLabelsOptions { | ||
userProject?: string; | ||
} | ||
|
||
export type GetLabelsResponse = [Metadata]; | ||
export type GetLabelsResponse = [unknown]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are API responses being labelled unknown
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my comments above, the short of it is that previously API responses were any
and due to the slightly different shapes of responses between Gaxios and teeny-request I chose to go with unknown
until we can more clearly type API responses.
acl?: AclMetadata[] | null; | ||
autoclass?: { | ||
enabled?: boolean; | ||
toggleTime?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be Date
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nvm!
acl?: AclMetadata[] | null; | ||
autoclass?: { | ||
enabled?: boolean; | ||
toggleTime?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nvm!
acae384
to
46bef73
Compare
* test: cleanup kms tests to avoid setting incorrect keys (#2213) * chore(deps): update dependency c8 to v8 (#2221) * feat!: better typing for metadata * more metadata typing * fix merge problems * remove extend * fix merge conflicts --------- Co-authored-by: Mend Renovate <[email protected]>
* refactor!: Remove `extend` and Treat Provided Options as Mutable (#2204) * refactor: Remove `extend` This is the prelimary, `src`-only commit. * fix: object merging * chore: remove log * chore: minor clean-up * chore: more clean-up * refactor: remove `extend` * perf!: treat provided options as mutable * feat!: stronger typing for lifecycle rules (#2215) * fix!: Do not return responsebody in delete, only raw response (#2236) * fix!: Remove extraneous validation in favor of server errors (#2237) * fix!: Remove extraneous validation in favor of server errors * remove test * refactor!: mark bucket.setLabels and associated interfaces as deprecated (#2214) * refactor!: mark bucket.setLabels and associated interfaces as deprecated * update addBucketLabel to use setMetadata * mark getLabels / deleteLabels deprecated, update samples * feat!: disable source maps for smaller bundle size (#2240) * feat!: better typing for metadata (#2234) * test: cleanup kms tests to avoid setting incorrect keys (#2213) * chore(deps): update dependency c8 to v8 (#2221) * feat!: better typing for metadata * more metadata typing * fix merge problems * remove extend * fix merge conflicts --------- Co-authored-by: Mend Renovate <[email protected]> * chore!: make node 14 the minimum version (#2230) * chore!: make node 14 the minimum version * move conformance test to node 14 * package upgrades, fix unit test compilation * update google owned deps * fix tests * remove node 12 kokoro folders * merge and fix issues * 🦉 Updates from OwlBot post-processor See https://github.com/googleapis/repo-automation-bots/blob/main/packages/owl-bot/README.md * export new metadata types from index * fix samples tests * fix system test --------- Co-authored-by: Daniel Bankhead <[email protected]> Co-authored-by: Mend Renovate <[email protected]> Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com>
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
Fixes #1817 🦕