This is done by duplicating `index.d.ts` into `index.d.cts`, and
modifying it for CommonJS. The same was done for type tests.
Unfortunately I was unable to find a way to re-use types without
drastically changing the code base.
To test this, a minimum TypeScript version of 4.7 is needed, so it has
been updated. The old types still work with older TypeScript versions.
Co-authored-by: Jay <jasonsaayman@gmail.com>
* feat: add boolean flag to mimic pre 1.x behavior for paramsSerializer custom function
* chore: update ParamsSerializer Readme
* fix: dont slice hash off URL if not appending params
* Omit nulls from formData serialization
* fix: dont add nulls or undefined values to arrays either
* readme update
* fix test
* chore: documentation
* chore: do TS properly
Co-authored-by: Jay <jasonsaayman@gmail.com>
* test: Failed test
Param indexes from formSerializer and paramsSerializer receiving null
Closes#4959
* fix: Allow null to indexes in SerializerOptions
Closes#4959
Co-authored-by: Willian Agostini <willian.agostini@fleetcor.com.br>
Co-authored-by: Jay <jasonsaayman@gmail.com>
* Added AxiosHeaders class;
* Fixed README.md href;
* Fixed a potential bug with headers normalization;
* Fixed a potential bug with headers normalization;
Refactored accessor building routine;
Refactored default transforms;
Removed `normalizeHeaderName` helper;
* Added `Content-Length` accessor;
Added missed `has` accessor to TS types;
* Added `AxiosTransformStream` class;
Added progress capturing ability for node.js environment;
Added `maxRate` option to limit the data rate in node.js environment;
Refactored event handled by `onUploadProgress` && `onDownloadProgress` listeners in browser environment;
Added progress & data rate tests for the http adapter;
Added response stream aborting test;
Added a manual progress capture test for the browser;
Updated TS types;
Added TS tests;
Refactored request abort logic for the http adapter;
Added ability to abort the response stream;
* Remove `stream/promises` & `timers/promises` modules usage in tests;
* Use `abortcontroller-polyfill`;
* Fixed AxiosTransformStream dead-lock in legacy node versions;
Fixed CancelError emitting in streams;
* Reworked AxiosTransformStream internal logic to optimize memory consumption;
Added throwing an error if the request stream was silently destroying (without error) Refers to #3966;
* Treat the destruction of the request stream as a cancellation of the request;
Fixed tests;
* Emit `progress` event in the next tick;
* Initial refactoring;
* Refactored Mocha tests to use ESM;
* Refactored Karma tests to use rollup preprocessor & ESM;
Replaced grunt with gulp;
Improved dev scripts;
Added Babel for rollup build;
* Added default commonjs package export for Node build;
Added automatic contributors list generator for package.json;
Co-authored-by: Jay <jasonsaayman@gmail.com>
* Added generic `AxiosAbortSignal` TS interface to avoid importing AbortController polyfill;
* Renamed `AxiosAbortSignal` to `GenericAbortSignal` to use the same naming style as `GenericFormData`;
* Added TS test for `GenericAbortSignal` interface;
Co-authored-by: Jay <jasonsaayman@gmail.com>
* Distinguish request and response data types
* Fix Axios headers type
`axios.headers` is not of the same type as `request.headers`, so a new type
`AxiosDefaults` was introduced
* Replace grunt-ts with dtslint
This asserts that the type definitions are valid in the specified TypeScript
version and above. This is the same tool that is used by DefinitelyTyped.
* Remove grunt-ts
* Restore typescript dependency
* Fix missing semicolons
Co-authored-by: Claas Augner <github@caugner.de>
Co-authored-by: Jay <jasonsaayman@gmail.com>
This requires TypeScript users to explicitly define the type of the data they
are consuming.
Before this, data was `any` by default. This means TypeScript consumers didn’t
get type safety if they forgot to specify the type.
Technically this is a breaking change for TypeScript users, as this will report
errors if they forgot to specifiy the response type. The simplest workaround
would be to explicitly set the response type to `any`, so it’s not breaking
much.
The `unknown` type is probably a slightly better fit, but this requires
TypeScript ^3.
`data` is still `any` in the very specific use case mentioned in
https://github.com/microsoft/TypeScript/issues/38969
Co-authored-by: Jay <jasonsaayman@gmail.com>
* Improved type-safety for AxiosRequestConfig
- AxiosRequestConfig is now a generic type whose template corresponds to data
Signed-off-by: Carlos Chida <carlos.chida@starchitecture.eu>
* Fixed tests
- TS tests now match the behaviour described in the PR
Signed-off-by: Carlos Chida <carlos.chida@starchitecture.eu>
Co-authored-by: Jay <jasonsaayman@gmail.com>
Remco Haszing