Having trouble importing deepmerge with Webpack

[GioSensation]

When importing deepmerge with import * as merge from 'deepmerge'; throws Error: merge is not a function in the app, while the tests run just fine.

When importing with import merge from deepmerge;, the app works fine, but the jest tests throw TypeError: deepmerge_1.default is not a function`.

I have temporarily patched the issue in my code with an if/else block to reassign the correct function to the variable, but I feel there must be a better way.

Maybe jest is misconfigured. Has anyone ever encountered a similar issue or can provide a configuration template that is proven to be working?

This describes a similar issue to what I am experiencing aurelia/skeleton-navigation#606, though I am not using Aurelia, nor Moment. It just seems like the same kind of problem.

---

Node version: 8.6.0
NPM version: 5.5.1
Webpack version: 3.6.0
Typescript version: 2.5.3
deepmerge version: 2.0.1

---

tsconfig.json

{
  "compilerOptions": {
    "outDir": "./dist/",
    "sourceMap": true,
    "noImplicitAny": false,
    "module": "commonjs",
    "target": "es5",
    "lib": ["es7", "es2017", "dom"],
    "jsx": "preserve",
    "allowJs": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "**/*.test.ts"]
}

---

.babelrc

{
  "presets": ["env", "react"],
  "plugins": [
    "react-css-modules"
  ]
}

---

jest.config.json

{
  "transform": {
    ".(ts|tsx)": "<rootDir>/node_modules/ts-jest/preprocessor.js"
  },
  "testRegex": "(/__tests__/.*|\\.(test|spec))\\.(ts|tsx|js)$",
  "moduleFileExtensions": ["ts", "tsx", "js", "jsx", "json"]
}

[TehShrike]

import * as merge is incorrect - assuming your bundler is picking up the ES module, then you're loading the ESM build of the package, which only exposes a default export. import merge from 'deepmerge' is correct.

I would guess that there is different bundling/module loading happening between typescript and jest. I'm not familiar with either of them, but my clue to you is to make sure that they're both either paying attention to the module field in deepmerge's package.json (if you want them to pick up the ESM version), or they're both ignoring it (if you want them to pick up the UMD version).

[richardschneider]

I'm not using TypeScript, just JS on the browser and on node. v2.0.2 works on node, but fails with the error on a browser. Reverting to v1.5.2 works on both environments.

[TehShrike]

@richardschneider What bundler are you using? What is the error message?

[richardschneider]

@TehShrike I'm using webpack. The error is TypeError: deepmerge is not a function.

See code at https://github.com/richardschneider/ipfs-encryption/blob/master/src/keychain.js#L80

[TehShrike]

I couldn't find any webpack config in that repo, but I'm no Webpack expert anyways.

In any case, I can guess at the problem pretty easily - your Webpack is configured to load in the ESM module, and is probably exposing default exports as a default property instead of the object you get when you require.

There are lots of ways you could fix this - you could const deepmerge = require('deepmerge').default, or you could switch your project over to using ES modules and do import deepmerge from 'deepmerge', or you could configure Webpack to ignore the module setting in package.json and just pull in main, since it looks like you don't care about ES modules, or you could configure Webpack to return the default export as the object returned by require instead of returning { default: deepmerge }.

If you want your un-built code to work in node.js, I'm guessing you'll want to do one of the two latter options.

[GioSensation]

Just to update the issue, I have solved this by importing explicitly the file I want, es.js, like this:

import merge from '../node_modules/deepmerge/dist/es.js';

I am not particularly happy about this, because if the name or path to the file change, the import will break. It is still the best solution I could find.

I have asked a question on StackOverflow to see if anybody had any insights to offer, but no answers thus far.

I guess you can close this issue if you have nothing to add.

Thanks.

[TehShrike]

@GioSensation You still haven't responded to my earlier message - it looks like you have two bundler environments, and they're both resolving modules differently. This doesn't have anything to do with this package using Rollup to bundle, it has to do with your bundlers respecting the main vs module fields in package.json.

A quick search of issues in the Jest repo turns up this: jestjs/jest#2702

It looks like somebody in that thread figured out a workaround for Jest.

[GioSensation]

Thanks. I will look into it and wait for the Jest team to integrate that pull request.

Cheers!

[Tarnadas]

Could this be reopenend?
The problem still persists and I don't feel like const merge = require('deepmerge').default is an ideal solution.
My app won't compile when I use import merge from 'deepmerge' with TypeScript 2.8 and Webpack 3.10.0, so it's not just affecting jest tests.

[TehShrike]

As long as your bundler respects the module field in package.json (which webpack claims to support), everything should work fine.

The package.json's module field points to es.js, which is a traditional ES module that exports a single default.

The package.json's main field points to umd.js, which is a bog-standard UMD file compatible with CommonJS and AMD bundlers.

Which one of those do you want your bundler to pick up? That is up to your project's configuration.

As far as I know, deepmerge's two entry points are the epitome of bundler-friendliness. Any issues should be the result of a misconfiguration or a bug in the bundler that you're using.

I don't know if it's a configuration issue or a bug, but it sounds like some combination of Typescript + Webpack has an issue out of the box.

[leoalves]

@Tarnadas
The issue with typescript is that the types are wrong.

If you edit the file index.d.ts from node_modules/types/deepmerge and change the export from
export = deepmerge; to export default deepmerge you can import it as import deepmerge from 'deepmerge'

If you want to import as import merge from 'deepmerge' you need to replace all references in that file from deepmerge to merge.

I am not sure if the typings reflect the most up to date version of the library. There is only one method that I use and for that one is working.

[TehShrike]

ooooh, is that why people are having difficulty with TypeScript?

Where are people getting these types from? Can somebody update them?

Does Typescript pull from module by default?

[leoalves]

There is a single repository that most common libraries types are there. It's mostly updated and maintainted by the community. https://github.com/DefinitelyTyped/DefinitelyTyped. The issue is that a lot of times they are not up to date with the library and this can cause issues when compiling.

In this case the problem is more with how TypeScript import works. TypeScript threats CommonJS/AMD/UMD modules in the same way as ES6 modules. When you do import * as merge from 'deepmerge' is the same as merge = require('deepmerge'). This doesn't work for your library.

The other way would be import merge from 'deepmerge' which is the same as merge = require('deepmerge').default. This would work for your library, but the typescript compiler has a configuration option called noImplicitAny. If this option is enabled the typescript does not compile if the type is any. That's the case for your library since you don't have typings.

This option is not enabled by default, but since @Tarnadas was complaining about compiling issues, I figured that this was enabled for him. I also assumed he was using the types from DefinelyTyped. That's why I suggested changing that file.