deepmerge: [Webpack] Uncaught TypeError: deepmerge is not a function

Hi,

I’ve been using deepmerge in many of my libraries, mostly private but a few of my public ones as well. The most popular library of mine to use it, webdav, was recently updated to use deepmerge 2 - the import of deepmerge broke:

Uncaught TypeError: deepmerge is not a function
    at Object.getDirectoryContents (factory.js:118)
    at eval (main_init.js:86)

This has only occurred for me in the 2.* releases. I use commonjs to import deepmerge. The library is basic Javascript compatible with NodeJS 4 and upwards. I’ve tested that this breaks in a couple of webpack configurations.

EDIT: I’ve created a reproduction.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 20 (11 by maintainers)

Most upvoted comments

But that would mean that the bad bundlers would win!

TehShrike on May 29, 2018

This issue is still happening for me. The exact stack trace is

Uncaught (in promise) TypeError: (0 , _deepmergeTs.deepmerge) is not a function at LocalizationStore.js:74:1 at createStoreImpl (vanilla.js:30:1) at createStore (vanilla.js:34:1) at createImpl (index.js:19:1) at create (index.js:27:1) at createStore (LocalizationStore.js:71:1) at createStore (LocalizationStore.js:205:1) at Provider (context.js:15:1) at renderWithHooks (react-dom.development.js:14969:1) at mountIndeterminateComponent (react-dom.development.js:17731:1)

I didn’t change any dependencies and today it just began happening. Any ideas as to why this is?

AppointMike on Oct 9, 2022

Have you considered the option to remove this line? https://github.com/KyleAMathews/deepmerge/blob/dfdb7239fff13385d44b5257f17a7423b8421678/package.json#L20

oliviertassinari on May 28, 2018

If you’re controlling the code that is importing deepmerge, you can always const merge = require('deepmerge').default and you’ll get the function you want.

TehShrike on Feb 27, 2018

I asked a person who knows better than me, and it sounds like that particular path forward isn’t guaranteed to be The Right Way, but seems reasonable for now.

TehShrike on Aug 29, 2018

If it also follows “module” even for source files using cjs, that’s indeed a bit weird

Yeah, that’s the crux of the Webpack bug I think. I tried to suggest changing that in this comment:

One potential solution would be: when require is used, prioritize the main entry point over the module entry point.

I didn’t know that Webpack was inferring anything from file extensions already, that’s interesting.

I’m open to any pull requests that implement the three steps I gave a couple posts up - if nobody else implements that, I’ll probably get around to it eventually.

At the very least, I’d like to get that done by the time ESM imports land in node.js unflagged.

TehShrike on Aug 25, 2018

@TehShrike I’m sorry but I believe you’re the one being wrong. There is virtually no chance your proposition will ever get approved by the Webpack team, since there is virtually no chance this will end up being the behaviour of node’s loader. Of course, this is still under discussion (mjs extension debate), but it will most likely look like this. This link also provides some recommandation for library author to support both esm and cjs. You may want to use these.

QuentinRoy on Aug 25, 2018

I opened an issue with Webpack: https://github.com/webpack/webpack/issues/6584

TehShrike on Feb 26, 2018

That’s excellent. If you’re okay with https://github.com/perry-mitchell/repo-deepmerge-webpack/pull/1 and merge it, I’ll make an issue over at Webpack.

TehShrike on Feb 26, 2018