iconv-lite: Not working with Karma and Webpack 4

Hi,

I’ve a strange bug. All works correctly when I run my application in production, but I can’t run my unit tests because of your module… Removing all require('iconv-lite') in my code resolve the problem.

I’m using Webpack 4, Karma 3, ES6.

This is the error I get:

Electron 3.0.2 (Node 10.2.0) ERROR
  {
    "message": "Uncaught TypeError: __webpack_require__(...) is not a function\nat webpack:///app/node_modules/iconv-lite/lib/index.js:144:27 <- index.js:58520:48\n\nundefined",
    "str": "Uncaught TypeError: __webpack_require__(...) is not a function\nat webpack:///app/node_modules/iconv-lite/lib/index.js:144:27 <- index.js:58520:48\n\nundefined"
  }

Have you any Idea of what this could be ? Thanks

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 8
  • Comments: 29 (9 by maintainers)

Commits related to this issue

Most upvoted comments

As @Feverqwe said in #205 : adding

{
  test: /node_modules[\/\\](iconv-lite)[\/\\].+/,
  resolve: {
    aliasFields: ['main']
  }
}

to the webpack module.rules solve my problem. Thanks for the workaround !

But I think that @whitehat101 PR #203 is a better solution and hope it will be merged soon.

I ran into the same issue in an electron environment (using vue-cli-plugin-electron-builder).

I believe the problem originates from these configurations:

  1. When building electron app, webpack is configured to use target ‘web’ or ‘electron-renderer’.
  2. This webpack target in turn takes browser property into account. In this case, webpack ignores streams.js and extend-node.js from bundling because they are set to false in the browser property in the package.json.
  3. index.js checks for node process and environment to determine if it is in a node environment. But in the case of electron, it is both a browser environment and a node environment. So iconv thinks it is in a node environment when the bundler thinks it is bundling for a web environment. This leads to __webpack_require__(...) is not a function error because streams.js is never bundled.

@Qualinost1 open your-project-folder/node_modules/iconv-lite/lib/index.js in a text editor. Then change therequire('something')() statements on line 145 and 148 to require('iconv-lite')

modify require("./streams")(iconv); to require("./streams.js")(iconv); modify require("./extend-node")(iconv); to require("./extend-node.js")(iconv); can hack the problem

This is more or less same issue as I ran into (and found a fix #203) while using mailparser with Webpack.

https://github.com/ashtuchkin/iconv-lite/blob/696be8a260a9988caba0092bb5a734a96ff9bf58/lib/index.js#L138-L145

Webpack doesn’t like require(...)(...). It transforms the require() into an empty object which can’t be invoked as a function. My environment didn’t define process , but when I persuaded the code to enter the if block, I got the same __webpack_require__(...) is not a function error.

Getting rid of the require(...)(...) and rewriting ./streams to require('iconv-lite') instead of module.exporting a function, fixes the error and provides a functional iconv-lite with stream support in a Webpack environment.

Tested, works great.

Both browserify and webpack will exclude streams module by default, so just using any of these tools in default mode should work.

Do you have any specific problem? If yes, then could you open a new issue and describe it, ideally with a way to reproduce it?

This issue is about iconv-lite throwing exception when used with Webpack and Karma and I wanted to keep unrelated discussions separate. Thank you!

On Fri, Jun 12, 2020, 03:02 Grzegorz Leoniec notifications@github.com wrote:

@ashtuchkin https://github.com/ashtuchkin could you provide an example of how to achieve this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ashtuchkin/iconv-lite/issues/204#issuecomment-643104809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEZKHLUM7G333Z6ZIRNSQLRWHHKDANCNFSM4FZN6GYA .

I can confirm the workaround/fix(?) from @joostblok worked for me, but I have no idea what this does 😄

This was due to an upgrade to latest “express”-dependency in combination with electron 3.0.11 (dont know if this is important).