@DigitalBrainJS is this duplicative effort of #5108 ?

EDIT: I also found a bug with null values being included in the serialized params list and resolved those in the PR. TDD FTW

Hi,
Can you release a version with this fix? many of us can't upgrade to v1 without it

Hi,
Can you release a version with this fix? many of us can't upgrade to v1 without it

Interestingly this PR overlooks a couple of bugs

• slicing off the hash from the URL regardless of serializedParams being valid or undefined. Old behavior was inside of the if statement

• nulls still get added to the URL

I already had a fix for this exact thing (see #5108) but it still sits open. It allowed custom params serialzers based on a boolean flag and made use of the existing encode field. Even added unit tests for all these behaviors. Not sure why we're duplicating effort here. 🤷

EDIT: PR updated with bug fixes after merging this in

Hey! This feature made a breaking change on paramsSerializer option, we should change a major version for that please

Hey! This feature made a breaking change on paramsSerializer option, we should change a major version for that please

@Roriz No, the paramsSerializer option has been changed in v1.0.0-alpha.1 as intended. This PR only adds an assertion for the parameter, because non-TypeScript users may continue to use the old interface by passing in an erroneous option value, which will be ignored by Axios. The addition of the assertion is not a breaking change.

As you can see on issue #5142, from this PR forward we can't use the old interface for paramsSerializer

we can't use the old interface for paramsSerializer

Yes, the old interface has been refactored in v1.0.0-alpha.1, in other words, the old interface is not supported since v1.0.0-alpha.1. Please check the index.d.ts file to see the new paramsSerializer interface definition.
This PR doesn't change the option behavior, it adds runtime type checking.

Ok, we changed the interface on alpha.1, but we don't add any warning about the change in the runtime. And now we put a validation check in runtime, any application that uses this config will break without alarm.
Here where I work, we only discover after deploying production and creates a downtime =/

I see three problems here.
The new interface use the same name as the previous one.
A validation that throw an error instead of logging a warning has been added in a patch version.
The docs hasn't been updated in the meantime.