Might be a duplicate of #6262

I think we can close this since #6263 which is to solve #6262 is merged and released in v0.28.1. See: 3021e0d

No, it's not fixed. Just tested with 0.28.1.

Feel free to test yourself by making a request like in the initial comment and checking brower network inspector for what is being sent.
I've tried it on an client side (in a browser environment).

@rchl I see, perhaps it is a different issue. v0.28.1 allows you to have a custom paramsSerializer.serialize options which you could use to achieve what you expected, otherwise I'd say this is just a standardization, i.e. stringified params vs params by key

Would make sense to keep the old behavior to prevent breaking changes unless there is a good reason to deviate. And if there is then it should be clearly marked as a breaking change and there should be good reason for it (standards compliance or similar).

@briwa @rchl would anyone have an serializer options example that would restore the behavior to the version prior to 0.28?

@butchtm I've tried to replicate the serialization behavior that was implemented in prior versions to 0.28 below

/**
 * Creates a URL-encoded query string from a given set of parameters
 * @param {Object} params The parameters to encode into a query string
 * @returns {string} The URL-encoded query string
 */
function createQueryString(params: any): string {
    return Object.keys(params).reduce((x, key) => {
        const value = params[key];
        if (typeof value === 'object' && value !== null && !(value instanceof Date)) {
            return x + `${x.length ? '&' : ''}${encodeURIComponent(key)}=${encodeURIComponent(JSON.stringify(value))}`;
        } else {
            return x + `${x.length ? '&' : ''}${encodeURIComponent(key)}=${encodeURIComponent(value)}`;
        }
    }, '');
}

I've similarly observed a breaking change that I believe is related and was not included in the CHANGELOG.

Specifically, before 0.28.0, if I have a querystring like:

const qs = {
    foo: 1,
    bar: 'xyz',
    baz: { }
};

When passed to axios.get – like axios.get("https://some.uri", { params: qs }) – the resulting query params that are passed to https://some.uri in the constructed request are:

foo=1&bar=xyz&baz=%7B%7D

In 0.28.0, that same request yields the following querystring params (excluding the baz param entirely):

foo=1&bar=xyz

This is a seemingly understandable optimization, but is in fact a breaking change for anyone who relies on that functionality to remain as-is.

it seems the problem has resolved in this issuse,but the lastest version v0.28.1 also has this problem

Any update of this? Version v0.28.1 does not solve this issue, is there an ETA for this fix?

Have to say this is very badly handled and like makes really wonder should one even try to use the newer axios versions in the future is this is how the project is maintained.

Minor release. Breaking change. No mention about it. Then releases a patch version that has ability to control it, but no mention on officially how to keep the backwards compatible behavior. And then 🦗 🦗 🦗