`v9.0.5` is causing other libraries to fail due to a TypeError

[jjranalli]

An error seems to have been introduced in v9.0.5 and has caused the following issues in web3-storage and js-ipfs which depend this library.

web3-storage/web3.storage#471
ipfs/js-ipfs#3838

The error is the following: TypeError: mergeOptions__default.default.bind is not a function

Manually installing v9.0.4 seems to fix the issue

[achingbrain]

How can I replicate this? I've tried running https://github.com/max-andrew/web3-storage-test but I get an error when I open the page:

[jjranalli]

I'm not the author of the reproduction repo, but this error seems to be caused by someImage not being of the expected File[] type.

Anyway you can comment that section (lines 12-14), as the error (if it appears) is caused by line 10, where the web3Storage client is initialised

[achingbrain]

If I comment those lines out, I don't see any errors at all. v9.0.5 is present:

$ npm ls ipfs-unixfs-importer
web3-storage-test@0.1.0 /Users/alex/Documents/Workspaces/max-andrew/web3-storage-test
└─┬ web3.storage@3.3.2
  └─┬ ipfs-car@0.5.8
    └── ipfs-unixfs-importer@9.0.5

[jjranalli]

I suspected that from your previous reply. Could it be caused by some specific configuration, or a global dependency that you have installed? I'm not sure what details I should give you to reproduce the issue

If it can be of help I'm attaching the full error I get whenever I install v9.0.5.

Uncaught TypeError: mergeOptions__default.default.bind is not a function

    at eval (VM3380 options.js:11)
    at Object../node_modules/ipfs-unixfs-importer/cjs/src/options.js (_app.js?ts=1631544537217:5938)
    at Object.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)
    at eval (VM3379 index.js:6)
    at Object../node_modules/ipfs-unixfs-importer/cjs/src/index.js (_app.js?ts=1631544537217:5927)
    at Object.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)
    at eval (VM3378 index.js:5)
    at Module../node_modules/ipfs-unixfs-importer/esm/src/index.js (_app.js?ts=1631544537217:9084)
    at Module.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)
    at eval (VM3344 index.js:8)
    at Module../node_modules/ipfs-car/dist/esm/pack/index.js (_app.js?ts=1631544537217:8765)
    at Module.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)
    at eval (VM3338 lib.js:11)
    at Module../node_modules/web3.storage/src/lib.js (_app.js?ts=1631544537217:9656)
    at Module.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)
    at eval (VM3337 web3Storage.ts:2)
    at Module../lib/web3Storage.ts (_app.js?ts=1631544537217:4449)
    at Module.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)
    at eval (VM3274 handleCreateProduct.ts:12)
    at Module../lib/handleCreateProduct.ts (_app.js?ts=1631544537217:4163)
    at Module.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)
    at eval (VM2994 AddProductForm.tsx:12)
    at Module../components/ui/AddProductForm/AddProductForm.tsx (_app.js?ts=1631544537217:3107)
    at Module.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)
    at eval (VM2993 index.ts:5)
    at Module../components/ui/AddProductForm/index.ts (_app.js?ts=1631544537217:3118)
    at Module.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)
    at eval (VM2835 index.ts:53)
    at Module../components/ui/index.ts (_app.js?ts=1631544537217:4152)
    at Module.options.factory (webpack.js?ts=1631544537217:685)
    at __webpack_require__ (webpack.js?ts=1631544537217:37)
    at fn (webpack.js?ts=1631544537217:354)

[achingbrain]

I've got no specific config, I just cloned the repo and ran the commands. No global deps to speak of:

$ ls -l /Users/alex/.nvm/versions/node/v16.8.0/lib/node_modules/
total 0
drwxr-xr-x   9 alex  staff  288 31 Aug 12:03 david
drwxr-xr-x   9 alex  staff  288  6 Sep 18:52 iim
drwxr-xr-x  12 alex  staff  384 25 Aug 22:39 npm

[jjranalli]

The only thing that comes to mind is I'm running on Node v14.16.1

(Anyway I opened the issue as I was not the first one to stumble upon it, and I thought you guys should be aware. Feel free to close it if you don't deem it relevant, I'll make sure to let you know in case I discover anything else)

[achingbrain]

I just tried with node@14.17.5, still no error.

The weird thing is there's no difference in the published cjs version of /src/options.js between 9.0.4 and 9.0.5:

• https://unpkg.com/ipfs-unixfs-importer@9.0.4/cjs/src/options.js
• https://unpkg.com/ipfs-unixfs-importer@9.0.5/cjs/src/options.js

merge-options also hasn't seen an update in 10 months: https://www.npmjs.com/package/merge-options

It may have something to due with Next.js? It lets you use esm syntax but it's pulling in the cjs version instead, which doesn't sound right.

The exports map of node_modules/ipfs-unixfs-importer/package.json is:

"exports": {
    ".": {
      "browser": "./esm/src/index.js",
      "require": "./cjs/src/index.js",
      "import": "./esm/src/index.js"
    }
  }

Could you maybe try swapping the "require" and "import" entries in your local copy?

Failing that, it might be using the "browser" override from the same file (though it shouldn't, it should use "exports" since it's present):

"browser": {
    ".": "./cjs/src/index.js"
  },

Could try changing that to the esm version?

[achingbrain]

Aha, I can replicate if I use yarn to install the deps, it doesn't happen if I use npm.

[jjranalli]

Yup, that seems fishy. I definitely might be wrong, but it seems index.js of the esm version is pulling the cjs version.

So looking at files changes in 9.0.5, the issue may have been generated here? -> https://github.com/ipfs/js-ipfs-unixfs/compare/ipfs-unixfs-importer@9.0.4...ipfs-unixfs-importer@9.0.5#diff-401848602b4e0efacd6fff0644f1628562c8b75a990455ede85a111ce67af998

With respect to the changes you suggested, swapping import with require doesn't change anything. Also I'm not directly importing the package, it's ipfs-car the one which is importing ipfs-unixfs-importer

I also tried enabling the experimental esm external flag in nextjs, but nothing changed.

[achingbrain]

Installing the deps of the repro project with yarn results in lots of weird behaviour - source maps are broken, esm->cjs transiplation is broken, and even doing a production build of the app is broken.

Install them with npm and everything works as expected - source maps, production builds, esm, everything.

Comparing the dep tree between the two shows some small differences but nothing obvious (to me, though I don't use next.js) so I'm not sure what the problem is, but it's almost certainly between next.js/babel/webpack, and not something to do with this module, though I will happily merge any PR that fixes the issue if that's the case.

I would open an issue against next.js with the repro repo, and in the meantime use npm instead.

[jjranalli]

I should have specified that I also use npm, but still face the issue.

I'm also unsure of the nature of the problem here, the only thing I can say for certain is that v9.0.4 works fine on my end.

Will follow up on the issue in case I discover anything relevant, in the meantime thanks for looking into it!

[jjranalli]

v9.0.6 (#173) seems to have fixed this. Thanks @achingbrain!

[achingbrain]

The root issue appears to have been a bug in webpack, but as you've found it's fixed now: webpack/enhanced-resolve#304