This repository was archived by the owner on Oct 17, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 120
fix(types): use Metadata types for apiResponse #277
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
@JustinBeckwith is this the thing you meant we removed that shouldn't have been there? Did
request
ever actually exist onGoogleAuthOptions
? I don't see it here: https://github.com/googleapis/google-auth-library-nodejs/blob/37bb8c7cd0a6501103274284d9cddd6816cc881e/src/auth/googleauth.tsIf it was just a pretend setting, then I would say non-breaking is okay, since it never had functionality anyway. Sorry if I missed something!
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.
Aye, that was the thing. This allowed the user to technically override the implementation of the
request
module used. We did this in other modules in a way that was totally internal, but for some reason it was exposed here publicly. Theoretically - someone could have been passing in the fullrequest
module here, hoping to use that instead ofteeny-request
. It's a stretch.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.
Sorry in advance, because I'm trying to follow along with the history of the changes
We removed the
requestModule
option from common a couple of months ago, which was a breaking change. So did this library actually intend to support the feature, but we forgot to remove the code here?Here's the code as it is today in this repo:
So, while the user's
options.request
is passed toService
, it would have always been ignored in favor of theconfig.requestModule
that we set. Here was the code in common, before we deleted it (source):Admittedly, trying to follow along with
request
vsrequestModule
andoptions
vsconfig
and the ordering of assignments in the constructor of this module creates loopholes that I can't really find my way out of. But to me, it seems like even though we said we acceptedoptions.request
, it never did anything anyway-- especially since even if we had all of our settings correct, it wouldn't have made a difference since the feature was killed upstream in common.