Export type change in 3.2.1+ after bundling (formerly: TypeError: axiosRetry is not a function)

[dominics]

Hello! I saw #181 and I think I'm experiencing something similar when trying to bundle a dependency (analytics-node) that happens to require axios-retry. The library in question loads axios-retry with require(), BUT Webpack seems to bundle the ESM export instead, causing the original issue - but only post-3.2.0 (i.e. a breaking change since then)

#181 didn't have good reproduction instructions, so I've made sure to isolate the problem in a repo: https://github.com/dominics/axios-retry-bundle-repro - an excerpt from the README is:

• In the 3.2.0/ directory, the dependencies include "axios-retry": "3.2.0"
• In the 3.2.1/ directory, the dependencies include "axios-retry": "3.2.1"

(That's the only difference). Each has a Webpack install, with a very simple configuration:

module.exports = {
    entry: "./index.js",
    output: {
        filename: "bundle.js",
        libraryTarget: "commonjs",
    },
};

There's a yarn test script in each directory. It makes a webpack bundle of this script and runs it:

var axiosRetry = require('axios-retry')
console.log(axiosRetry)

To reproduce the issue, I recommend running:

cd 3.2.0 && yarn install && yarn test && cd ..
cd 3.2.1 && yarn install && yarn test && cd ..

Results after bundling

3.2.0 returns the following function:

[Function: O] {
  isNetworkError: [Function: i],
  isSafeRequestError: [Function: a],
  isIdempotentRequestError: [Function: c],
  isNetworkOrIdempotentRequestError: [Function: R],
  exponentialDelay: [Function: l],
  isRetryableError: [Function: f]
}

However when we try to bundle 3.2.1, we get a breaking change, and get a module object instead (newer versions such as 3.2.4 and 3.3.1 return the same):

Object [Module] {
  isNetworkError: [Getter],
  isRetryableError: [Getter],
  isSafeRequestError: [Getter],
  isIdempotentRequestError: [Getter],
  isNetworkOrIdempotentRequestError: [Getter],
  exponentialDelay: [Getter],
  default: [Getter]
}

Summary

It seems that, if you're using a common bundler with default settings, you'll likely experience #181 as a breaking change on a patch release, and this problem seems to remain in 3.3.1 - I would guess the likely issue is how the bundler is handling the package.json changes that were made in 3.2.1 - probably Webpack 4 is grabbing at the wrong import (e.g. maybe because the ESM module is listed in package.json as the module field? yet Webpack 4 doesn't understand to use the ESM module struct's default property? something like that)

This could be entirely a problem with how the bundler is choosing which export to bundle, and it might even be unfair to expect libraries to think of how they're bundled as part of their public interface. It may be fair to say "use a different bundler then!". But practically, 3.2.1+ will break at runtime for people who are trying to bundle their dependencies, when 3.2.0 was working for them, so I still felt it was worth it to isolate that issue.

Hope the reproduction helps! I'm not sure what the fix is, or whether the situation is even fixable.

[dominics]

Updated the repro repo to have versions 3.2.1 and 3.3.1 as well as the original 3.2.0 and 3.2.4 that were relevant to #181

[mindhells]

Interesting, this is what I found out so far:

• you are using webpack 4
• for webpack 5 there's a clear documentation about how package-exports works (look at the "notes about ordering section" which is particularly relevant in this case)
• for webpack 5 works as expected
• for webpack 4, it seems it doesn't matter what you put in the "exports" property of the package.json, when the prop "module" is defined it will stick to that

There's probably something that can be tuned up in the webpack config for webpack 4 to make it work, not sure we can do anything (a part from removing the "module" property) Any ideas?

[mindhells]

And BTW, @dominics thanks a lot for taking the time to create the example.

[dominics]

There's probably something that can be tuned up in the webpack config for webpack 4 to make it work

Yup, I I think this is: adding a resolve.alias config option from { axios-retry: "axios-retry/index.js" } so that Webpack doesn't need to look at the package.json

removing the "module" property

I suspect that might be a breaking change for anyone now relying on it?

I can't think of much that can be done - the main lesson I'm taking from this is my bundler is too old!