feat(openapi-fetch): add support for arbitrary method #2063
Conversation
👷 Deploy request for openapi-ts pending review.Visit the deploys page to approve it
|
🦋 Changeset detectedLatest commit: 2335067 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
kerwanp
added
enhancement
kerwanp
force-pushed
the
feat/fetch-request
branch
from
f23ebc0 to
53b3c32
Compare
kerwanp
force-pushed
the
feat/fetch-request
branch
from
53b3c32 to
2335067
Compare
| @@ -0,0 +1,5 @@ | |||
| --- | |||
| "openapi-fetch": minor | |||
There was a problem hiding this comment.
This is a patch because it doesn’t introduce a breaking change (that I’m aware of)
| "openapi-fetch": minor | |
| "openapi-fetch": patch |
There was a problem hiding this comment.
According to semver:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
As it brings a new feature and is backward compatible. Imo it should be a minor
There was a problem hiding this comment.
That only applies for > 1.0! For 0.x, it’s more standard to smush bugfixes/features into patches, and use minor for breaking changes. It helps people plan more accordingly. Semver dictates that 0.x releases are allowed to make breaking changes at any time, and even though this method isn’t “official,” it’s a very common pattern, and one that openapi-fetch has followed since the beginning.
Put another way, for 0.x, you have to either use minor for breaking + feature, or patch for feature + bugfix. It’s basically a coin toss, and we have been historically going with the latter for now.
But you are correct—that becomes the pattern as soon as 1.0 is released and thereafter
There was a problem hiding this comment.
I was not aware of this! Thanks for letting me know, I'll update that
Changes
This Pull request closes #1808 by providing a
requestmethod that accept a method as its first arguments allowing to pass anyHttpMethod. Making library authors' life easier.This does not introduce any breaking change.
How to Review
A new
requestshould be available on the client that must behave exactly like the otherGET,OPTIONS, etc methods but with the ability to pass the HttpMethod as first parameter.Checklist
docs/updated (if necessary)