weffe / axios-api-versioning Goto Github PK
View Code? Open in Web Editor NEW:diamond_shape_with_a_dot_inside: Add easy to manage api versioning to Axios
Home Page: https://weffe.github.io/axios-api-versioning
License: MIT License
:diamond_shape_with_a_dot_inside: Add easy to manage api versioning to Axios
Home Page: https://weffe.github.io/axios-api-versioning
License: MIT License
Found a problem that the type AxiosRequestConfigWithVersioning
does not pass a generic to AxiosResponse
because of this, the return type is any
export interface AxiosRequestConfigWithVersioning<T = any> extends AxiosResponse<T> {
__^
config: AxiosRequestConfigWithVersioning;
}
Currently, the key
names used for both Media Type and Query String are hardcoded as v
and api-version
respectively. It would be ideal to pass the key
name in as a config option to withVersioning()
.
e.g.
For Media Type:
withVersioning(axios, {
apiVersion: '2',
versioningStrategy: VersioningStrategy.MediaType
versionKeyName: 'my-custom-api-version'
})
For Query String:
withVersioning(axios, {
apiVersion: '2',
versioningStrategy: VersioningStrategy.QueryString
versionKeyName: 'my-custom-api-version'
})
Maybe keyName
can be ignored when the VersioningStrategy
is UrlPath
.
Something like this: https://codesandbox.io/s/k3j6p446kr?fontsize=14&view=editor
I think it's a good idea to add CI for this project.
I still need to figure out the integration tests using axios-mock-adapter
. But the other unit tests should work just fine.
0.19.0
to 0.19.1
.π¨ View failing branch.
This version is covered by your current version range and after updating it in your project the build failed.
axios is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.
The new version differs by 47 commits.
960e1c8
Releasing 0.19.1
8a9421d
Fixing typo in CHANGELOG.md: s/Functionallity/Functionality (#2639)
ee47120
If this place is false, it will report an error, so you should delete the useless code. (#2458)
03e6f4b
Fixing invalid agent issue (#1904)
dc4bc49
fix: fix ignore set withCredentials false (#2582)
13c948e
Remove 'includes' API, fix CI build failure (#2574)
fa6cf01
fixing Travis link (#2540)
a17c70c
Fix CI build failure (#2570)
1a32ca0
Remove dependency on is-buffer (#1816)
0cc22c2
Fix badge, use master branch (#2538)
8414664
Fix XSS logic that matched some valid urls (#2529)
bbfd5b1
Adding options typings (#2341)
55aaebc
Document fix (#2514)
86d7750
Update docs with no_proxy change, issue #2484 (#2513)
b0afbed
Adding Typescript HTTP method definition for LINK and UNLINK. (#2444)
There are 47 commits in total.
See the full diff
There is a collection of frequently asked questions. If those donβt help, you can always ask the humans behind Greenkeeper.
Your Greenkeeper Bot π΄
Currently, we are modifying the global AxiosRequestConfig
to add in apiVersion
and versioningStrategy
as optional properties. This is needed so TypeScript users can pass in those options on a request without getting any issues.
It would be better to find a different way to provide the same type safety without modifying the global AxiosRequestConfig
.
What I can think of is creating our own type AxiosRequestConfigWithVersioning
and exposing it. Then, recreate the axios interface with get
, post
, etc, to accept the AxiosRequestConfigWithVersioning
instead of AxiosRequestConfig
.
This also tightens things up in terms of type safety because as soon as you import this module then it automatically modifies AxiosRequestConfig
. If a TypeScript user creates an axios
instance that does not have versioning, they will still get the option to define apiVersion
and versioningStrategy
in the AxiosRequestConfig
which could be confusing.
Reference:
axios-api-versioning/src/types.ts
Lines 37 to 46 in f680e77
For the next version, I am in the process of trying to clean up the build process for this project. I would also like to clean up the way the custom Axios types (e.g. AxiosRequestConfigWithVersioning
) are exported since I feel like the current way is a bit cumbersome.
Instead of:
import { AxiosRequestConfigWithVersioning } from 'axios-api-versioning/dist/types/axios';
I would rather prefer:
import { AxiosRequestConfigWithVersioning } from 'axios-api-versioning';
I would like some feedback from those that use this library if this TypeScript change is a good Quality of Life change.
It would be great to add project examples for usage on both the browser and on nodejs apps.
Reference: https://github.com/Microsoft/aspnet-api-versioning/wiki/Versioning-by-Media-Type#custom-media-types
Should we support custom media types?
Currently, the mediaTypeKeyName and apiVersion is just appended to the Accept Header. The only way I can see this as a possibility is by providing a hook like mediaTypeFormatter(acceptHeader: string): string
. If a user provides their own mediaTypeFormatter
then we would use that instead of setting it ourselves like in the current way.
This isn't an issue but more so a reminder for my sake and for documentation purposes.
There has been a PR merged into the 1.0.0
release branch for axios that address my concerns for issue #5 and would let us drop the need for custom axios types like AxiosResponseWithVersioning
. It would also alleviate the need for me to keep the types in sync with the axios repo which is a nice benefit.
I have no idea when 1.0.0
version will be released but if it gets released and I haven't updated this project yet then feel free to ping me.
Have a good day! π
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.