deepMerge is not a function

[SettingDust]

The compiled js can't use

{
  default: [Function: merge] {
    options: { mergeArrays: true },
    withOptions: [Function (anonymous)]
  }
}

TypeError: deepMerge is not a function

[voodoocreation]

Hey - how are you using it?

If you're using it within some CommonJS code with require, you may need to do this instead:

const merge = require("ts-deepmerge").default;

Let me know if that helps. This package was designed for use within TS codebases with import/export syntax so it hasn't been thoroughly tested outside of that.

[SettingDust]

I'm using it in typescript. And I think I haven't compiled it to cjs. I'm looking into that
.swcrc

{
  "module": {
    "type": "es6"
  },
  "jsc": {
    "parser": {
      "syntax": "typescript"
    }
  },
  "sourceMaps": true
}

tsconfig

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ES2022",
    "esModuleInterop": true,
    "moduleResolution": "Node",
    "noImplicitOverride": true,
    "allowSyntheticDefaultImports": true,
    "sourceMap": true,
    "types": [
      "mocha"
    ]
  },
  "ts-node": {
    "swc": true
  }
}

[voodoocreation]

Can you show me how you're importing it and attempting to use it? I've never encountered this sort of issue within a TS codebase before - it generally just works like this without any issues, so it may be something to do with the way your project is being compiled?

import merge from "ts-deepmerge";

const obj = merge({ a: true }, { b: false });

I don't suppose your issue is being caused by allowSyntheticDefaultImports being set to true?

[SettingDust]

I guess the ts-swc-loader Im using for test with mocha caused that. I'm trying to dig it. I don't know if it is respect my swc config.

I think it isn't a problem of code

import deepMerge from 'ts-deepmerge'
deepMerge({ title }, ...it)

[voodoocreation]

Hmm it seems like something specific to your config/setup is impacting it somehow and causing the module to return the CommonJS module object rather than the default export from the module which would require you to import it like this instead:

import { default as merge } from "ts-deepmerge";

Would be good to try and track down what's causing it to behave differently though 🤔

Does removing the allowSyntheticDefaultImports property from your tsconfig.json help at all?

[SettingDust]

What's compiled manually(IDK if it as same as the loader's). Will it caused it?

import deepMerge from "ts-deepmerge";
deepMerge.apply(void 0, [
{
  title: title
}
].concat(_toConsumableArray(it)));

[SettingDust]

Does removing the allowSyntheticDefaultImports property from your tsconfig.json help at all?

Noop

Hmm it seems like something specific to your config/setup is impacting it somehow and causing the module to return the CommonJS module object rather than the default export from the module which would require you to import it like this instead:

import { default as deepMerge } from "ts-deepmerge"; not working

[voodoocreation]

I'm not too sure what you mean there. I just know that when consumed normally this issue doesn't occur. Has been tested in a number of different contexts (eg: using the TS compiler on its own, using Webpack etc) and they all resolve as expected.

You can test it out in this bare-bones TS template repo of mine if you like and perhaps compare your config to that, because that one works. It's quite hard to debug your project without having access to it I'm afraid... It just seems like something within your stack is causing the module to return an object instead of the actual module.

[voodoocreation]

@SettingDust did you get this working in the end? Just wondering if I can close the issue 🙏

[SettingDust]

@SettingDust did you get this working in the end? Just wondering if I can close the issue 🙏

No. I've switched from swc to esbuild and still error. Still testing

[SettingDust]

Can't explain the reason.
I guess it caused by exports.default which is a babel proposal(of course typescript use it too).
Maybe the project should be compiled to cjs(module.exports) and esm(export default)

Edit: seems there is a plugin to solve this https://www.npmjs.com/package/swc-plugin-node-cjs-interop

[voodoocreation]

Does that plugin enable it to work in your project? We have roughly 800 public GitHub repos depending on this package and none of them have had this issue, so it seems like it's a project configuration issue rather than an issue with the package itself.

If that plugin has allowed it to work, please let me know and I'll close this issue.

[SettingDust]

It's fine with https://github.com/qnighy/node-cjs-interop. The swc plugin not working qnighy/node-cjs-interop#43

[krailler]

I have same issue :(

[thyming]

I have the same issue too. I made a reproduction that I think boils down to having "type": "module" in the consuming project's package.json. With it, typescript is happy to compile the code using this library, but the compiled code fails at runtime. Without it, everything works correctly.

[thyming]

This seems to be a very similar problem and they have a workaround that may work here too without complicating the build hugely.

[voodoocreation]

Hmmm interesting... I'll have a look and see what I can do! 👀

[voodoocreation]

I've just published a new version which now properly supports consumers that use either ESM or CommonJS syntax.

Once you update to version 6.0.2 (fixed a couple of CJS bugs from the initial v6 release), it should now be able to automatically use our packaged ESM code in your native ESM projects without encountering this issue 🙏

[thyming]

Glorious! Thank you!

…

On Thu, Jan 26, 2023 at 8:14 PM Voodoo Creation ***@***.***> wrote: Closed #22 <#22> as completed. — Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ5N2N57GPFTT3OYSY6F7LWUMOOTANCNFSM6AAAAAARZJQ5QE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>