Here's a running example -- https://runkit.com/philipbjorge/axios-regression

Having a similar issue with our session based auth tokens not being merged either.

I _believe_ the fix is as simple as moving params to the property to the deepMergeProperties section. Diff here: https://github.com/axios/axios/compare/8d0b92b2678d96770304dd767cd05a59d37f12cf...zackseuberling:zs-fix-merge-params

@zackseuberling could you put in a pull request for this?

I have a same issue.

@jasonsaayman tests are now passing (for what I assume the correct behavior is) in #2196

hope release soon , the issue made me pretty annoying

Having the same issue. When is it going to be fixed?

Same here @wphestiraid 😬

Downgrading to 0.18.1 fixed it for me as a workaround! That has the security vulnerability fixed.

@serranoarevalo I think we can use 0.18.1 :smile:

This seems to also happen with method, if it's only specified in the create call and not the request. Took me all day to figure that out, definitely a breaking change. (Should this be a separate issue, or is it part of the same general problem?)

Same issue here

any news about this one ? when it will be fixed ?

any news about this one ? when it will be fixed ?

Just use v0.18.1 for the time being. ✈️

that's what i'm using, but i need to upgrade to v0.19.0 once this is fixed due to securtiy issues

that's what i'm using, but i need to upgrade to v0.19.0 once this is fixed due to securtiy issues

What kind of security issues? v0.18.0 had security issues, v0.18.1 is fine.

NPM is still flagging 0.18.1 as vulnerable during an audit - likely a red herring.

If you need to use axios 0.19 like me, you can managing the parameters like this and it should work fine for now as a workaround.

// Pass to create only these params
const instance = axios.create({
  headers,
  baseURL,
  timeout,
});

// Pass others to the instance request
instance.request({
  method,
  url,
  data,
  ...options,
});

Waiting for an official fix 😭

upvote. just spent the afternoon chasing down this bug and came here to write an issue.

Is there any progress to provide a fixup?

https://github.com/axios/axios/blob/v0.19.0/lib/core/mergeConfig.js#L18-L22

module.exports = function mergeConfig(config1, config2) {
  // eslint-disable-next-line no-param-reassign
  config2 = config2 || {};
  var config = {};

  utils.forEach(['url', 'method', 'params', 'data'], function valueFromConfig2(prop) {
    if (typeof config2[prop] !== 'undefined') {
      config[prop] = config2[prop];
    }
  });

the v0.19.0 code shows that mergeConfig(axios_instance.defaults, config)
only the request config.params get used.

Why a minor version not compitable with previous version?
No test for this?
I have to ask.

@magicdawn I think they messed up. I don't get what they are waiting for to merge the fix. Pls @emilyemorehouse, help us with https://github.com/axios/axios/pull/2196 🙏!

Any news? I got the same error then upgrade to latest version.

What is the problem is this ever going to get fixed!!

Took me a while to find this issue... annoying. Waiting on a fix too.

Might be a hack, but you can also patch the get method for a created axios instance:

const client = axios.create({
  baseURL: YOUR_URL,
})
client.originalGet = client.get
client.get = (url, { params, ...config }) =>
  client.originalGet(url, {
    ...config,
    params: {
      key: YOUR_API_KEY,
      ...params,
    },
  })


// use it like normal
client.get('/something', { params: paramsToMerge } )

I wrapped the create instance and patched all the methods like this:

export const createInstance = (config?: AxiosRequestConfig): AxiosInstance => {
  const instance = axios.create(config);

  // Patch methods to merge default params into each request.
  // https://github.com/axios/axios/issues/2190
  for (const [method, configIndex] of methodsToPatch as Array<[keyof AxiosInstance, number]>) {
    const orig = instance[method] as Function;
    // @ts-ignore
    instance[method] = (...args: any[]) => {
      if (!args[configIndex]) {
        args[configIndex] = {};
      }
      args[configIndex].params = {
        ...(instance.defaults.params || {}),
        ...(args[configIndex].params || {}),
      };
      return orig.apply(instance, args);
    };
  }

  return instance;
};

const methodsToPatch = [
  ['getUri', 0],
  ['request', 0],
  ['get', 1],
  ['delete', 1],
  ['head', 1],
  ['post', 2],
  ['put', 2],
  ['patch', 2],
];

For everyone looking for a workaround you could use mine (might not apply to all):

npm i qs

axios.interceptors.request.use(config => {
    config.paramsSerializer = params => qs.stringify({ ...params, myValue: 'foo' });
    return config;
}

@janpantel I'm curious, why not just modify the params?

axios.interceptors.request.use(config => {
    config.params.myValue = 'foo';
    return config;
}

@janpantel thanks I think it works that way, also is cleaner than the other alternatives

We have a very similar error.

In fact we can't even specify any instance params with axios.create().
Meanwhile we falled back to a request interceptor...

Same for me. Drove me nuts today! All was working fine. Then suddenly I was getting Authentication issues and CORS issues?! Yargh...

I worked out that I have updated from v18 to v19 and then inherited this bug I guess. It appears that the 'default' parameters that I defined in the instance definition (an old school authkey parameter) were not getting merged when I called that instance later on with new params, the new params killed the defaults :(.

Downgraded to version 18 solved it. Hope they fix it soon though, I like all my modules up-to-date! :P

I turn to use umi-request in node & browser now.
so far so good. 😄

The same problem is still exit since 2020.
Does it run as designed or when can this issue be resolved?

Axios Version: 0.19.0

Thanks for providing such a useful lib!

v0.19.1 still has this bug 😞

Fix this already. this is really annoying. took me 15 minutes to figure this bug.

Same problem here using [email protected]. Using interceptors as a workaround.

Still getting same issue with [email protected]. Downgrade axios to make it work.

npm install --save [email protected]

Having this issue as well. Please fix

some kind of endless drama

It's not even that the instance parameters wouldn't be merged with the call parameters. The instance parameters are not going into the parameters for the request at all. If I create an instance and define params, they are never be found in one of my get requests.

Downgrading was the easier option than defining the parameters with every get call.

Why is this issue closed? As @renestalder mentioned, in the last version, none of the instance parameters appear in any request which renders the create method somewhat pointless.

It's closed because it's fixed in #2656, but there's still no version for it.

I used interceptor as a workaround too, something like @cheelahim suggested:

axios.interceptors.request.use(config => {
  config.params. = {
    myValue1: 'foo',
    myValue2: 'bar',
    ...config.params,        
  }
    return config;
}

But still waiting for a new version to fix this bug.

Axios get & params

      const params = {
        name,
        id,
        pageIndex,
        pageSize,
      };
      const url = `/api/poi/query`;
      axios
      // .get(url, params)
      .get(url, {
        params,
      })
    .then(json => {
        // do something
      })
     .catch(err => console.log(`error`, err));

https://stackoverflow.com/questions/40947650/axios-get-in-url-works-but-with-second-parameter-as-object-it-doesnt

woah! almost 1 year later!

The bug still exist! Can't believe......

The fix has been merged in #2656 but a version for it has not been cut yet

Just downgrade to 0.18.0

Why it is closed?

Unfortunately fetch is out as soon as you need progress events or cancelation support.

Just pin your version to ^0.18.1.

@techouse moving to alternatives is better solution.

I have always liked using axios. But the idea that this fix has been there for this long and no one can manage to assign it to a version is just a joke it's time to move on. Or get someone to manage this that actually wants to progress the product.

Jon Alberghini
Director of Technology
[email protected]
o. 802-323-4558 | c. 802-323-4558 | www.legacyresearch.comhttp://www.legacyresearch.com

From: Evgeny notifications@github.com
Sent: Thursday, April 23, 2020 10:59:32 AM
To: axios/axios axios@noreply.github.com
Cc: Jon Alberghini jon@legacyresearch.com; Comment comment@noreply.github.com
Subject: Re: [axios/axios] Request params are not getting merged with instance params (#2190)

@techousehttps://github.com/techouse moving to alternatives is better solution.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/axios/axios/issues/2190#issuecomment-618445756, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AF6OZWIPRREAQP5OGY437X3ROBJVJANCNFSM4HRPA6AQ.

I think it's closed because a fix has been merged and is supposed to be released in v0.20.0 . See here

Same issue here, hoping it will be fixed soon!

+1. downgrading for now. smh.

@khastation @raphaelbadawi @jonathanalberghini @techouse @AndyOGo

Alternatives:

• Fetch and polyfill whatwg-fetch
• got
• ky
• node-fetch

@mahnunchik
Unfortunately fetch is out as soon as you need progress events or cancelation support.

@AndyOGo It can be implemented like https://javascript.info/fetch-progress

I found my way out using some deconstructing to separate the key param. Temporary code for sure, but since the merge is already done and 0.20.0 is underway, I'm really confident. Axios is still my way to go, even if I am experienced with fetch(). Things are usually so lean with Axios ;-)

Thanks @mahnunchik
Though I'm speaking about progress events for download and upload!

Thank you for your question @bdrtsky
Mainly for these reasons:

• fetch specifies several regressions compared to XMLHttpRequest
• cancelation becomes important as soon as you build large scale services
• I built a file uploader, so I need more sophisticated progress handling

This is closed due to the fix already being assigned to 0.20 release. We are currently working on that release the point of 0.20 is to get regressions fixed and release a stable Axios again.

This is work in progress, for updates check the 0.20 project.

Is it possible to put it in 0.19.3 patch version ? Defect cannot be closed if it is not fixed in the same minor release...

I have re-opened but we wont be releasing a 0.19.3. We would like to gain stability in a 0.20 release that removes all the regression from 0.18.0 to 0.19.2.

Seems the only possible solution rn is to downgrade.

When can we expect this elusive 0.20 release? Is there a beta version we can use in the mean time?

@adamreisnz I am working on the 0.20 release but there is still about 60 odd pull requests (brought this down from 120 odd), with some being very old and varied amount of work in checking and making sure these pull request either are still relevant, don't present a breaking change, have tests, don't include compiled files etc etc it is a labour. I endeavour to try get it into a pre-release by July at best. We would love help testing this release as we really want to get it right before we work on a v1.

It is an annoying problem, hope it can be fixed, is maintained for a long time.

want to get it right before we work on a v1

There's plenty of room in 0.x to make additional releases before 1.0.0; you don't have to cram everything into the next release. In fact, one could argue that would just make potential new bugs just harder to track down.

@markcarver Sure we could however Axios is seen as pre-release currently as without a v1 it looks to most people that Axios has not released a public API see SemVer PublicAPI. With v0.20.0 we would like to bring stability and fix most regressions from the 0.19.x branch as some problems presented in this branch as well as work on errors that are easy wins.

We also do need to clear the backlog of pull requests at the same time. It is very difficult to deal with 120 odd pull request where some of them were from as far back as 2017. I promise we will get to this issue, I am going nowhere and will be supporting and working on Axios as much as I can.

Thanks

I think there's just a lot of frustration building up, because we can't use certain plugins (e.g. axios cache adapter) unless we downgrade and lock in Axios at v0.18, or roll our own (unmaintained) version and apply the fix there.

This has been the case for quite a few months now, and I think everyone is just keen to see at least some fixes released.

Is it not possible to port some of the currently applied fixes and release a 0.19.x so that at least we can use the latest codebase? If you intend to go through another 120 pull requests, I am afraid we'll be waiting a long time until we see a 0.20 or v1.

I would personally opt for a more incremental approach, if possible.

@adamreisnz sure I would opt for increments too but there was alot broken from 0.18.x to 0.19.x and the idea was to try make a 0.20.0 release stable with some of the most pressing stuff in that release. We only have 60 pull requests left, I have already worked through the rest and some of those 60 are either tagged as wip or v1.

I know it has been a long time but I would like to get it right this time and not just release and break more things cause at this point that is largely possible. Also the build will need wide spread testing before it goes public. I get the frustration but if we don't get it stable and fix a ton of regressions we could release any number of increments, and still sit with over 200~ issues and 60~ pull requests that just sit there getting stale, as well as a still very broken Axios, maybe even more broken.

In addition I don't control releases at the moment and when I started helping I promised to get together a build that would fix regressions and the most pressing issues as well as not breaking anything else that worked previously. I take this pretty serious and would like to do that.

I can however try and get a 0.18.x release with any security issues etc fixed if that is something that would help?

I can however try and get a 0.18.x release with any security issues etc fixed if that is something that would help?

That would be awesome.

P.S.: We all appreciate the hard work you're doing by maintaining a package that is intricate to so many web projects. 😊

I can however try and get a 0.18.x release with any security issues etc fixed if that is something that would help?

Yes I concur, that would definitely be appreciated.

If you need any help testing some of the new stuff let me know I'd be open to doing that.

@adamreisnz could you test this branch: 0.20.0-beta.1

I can yes, will try to switch to that branch this weekend for one of our projects.

@jasonsaayman so far so good, 0.20.0 seems to be working well 👍

It seems, issue can be closed now

Closing after receiving feedback that this is now working as it should under the new release.