Debug: Cannot use debug with Rollup

[StreetStrider]

There're a troubles both using debug directly (via import debug from 'debug') and as a dependency to another package, with Rollup bundler.

1. import debug from 'debug':
   > Non-existent export 'default' is imported from node_modules/debug/src/browser.js

I believe this is because of that dynamic stuff.

1. import SocketIo from 'socket.io-client' which has debug as a dependency:
   > 'default' is not exported by 'node_modules/socket.io-client/node_modules/debug/src/browser.js'

As far as I understood, the main idea behind browser.js is to import kinda «base» debug object and upgrade it with browser-specific methods' implementations. I believe this can be rewritten in more static and bundler-friendly way. Like requiring base, propagate it with methods and then export as a default in different statements which would simplify the analysis by Rollup and other-like.

I'm not an active debug user, but debug is very popular tool, so many of my packages' of choice using it as a dependency. So I stumble upon it when bundling, from time to time. Leveraging any workarounds is diffcult, since I do not have precision control over dependencies of my dependencies.

[TooTallNate]

Patch welcome.

I'm reluctant to say that this is debug's fault. The code has been formatted this way for literally years, and works fine in Node.js and browserify and webpack and probably more bundlers.

Also related #438.

[StreetStrider]

@TooTallNate, hello.
I'll prepare a patch gladly.

The code is working in Browserify because this bundler doesn't do anything fancy with code. It just wraps modules in functions to create scopes and supply them with adequate require. I haven't been using Webpack, but I believe, it works the same way (at least in CJS «mode»).
As for Rollup, it treats files like real modules and tries to apply some analysis and tree-shaking, code removal. Since that, it requires from modules to be more static and stumbles when modules require actual code execution when initializing/requiring them. @Rich-Harris correct me, if I'm wrong.

[Rich-Harris]

@StreetStrider that's a fair assessment of what's happening. But it sounds like this is probably a fixable bug in rollup-plugin-commonjs — I suspect it just doesn't know what to make of this code:

exports = module.exports = require('./debug');

I've opened a related issue over there: https://github.com/rollup/rollup-plugin-commonjs/issues/204

[StreetStrider]

@Rich-Harris, if it can be fixed in plugin, that would be great, because I've been using the similar pattern in my CJS code as well. And probably other people too.

It's fixable indeed, I just didn't know how much you'd go in such cases.

[StreetStrider]

Damn. Expected to make this work via usual expression splitting, something like:

var base = require('./debug');

module.exports = base;

base.log = log;
// …

Not working at all. The error is the same.

Non-existent export 'default' is imported from <file>

[wildeyes]

Fails for me because of that line in webpack 2 and a .babelrc with { es2015: { modules: false } }.
In that configuration, it treats the code in a similar fashion to rollup, in the tree-shaking / real modules sense.
The exact error is Cannot assign to read only property 'exports' of object '#<Object>'. He doesn't like that debug accesses module.exports directly, Maybe webpack is expecting only "export X" statements.

This is probably a webpack / babel problem.

[aryzing]

[SOLVED]
Hi, I'm having a similar issue, and I suspect it might be related with this one. In my case, webpack can't find either fs or net

Module not found: Error: Can't resolve 'fs' in [path]/node_modules/debug/src
 @ ./node_modules/debug/src/node.js 184:15-28

Module not found: Error: Can't resolve 'net' in '[path]/node_modules/debug/src'
 @ ./node_modules/debug/src/node.js 191:16-30

Setting both of these to empty in webpack config sovles the issue,

  node: {
    fs: 'empty',
    net: 'empty',
  },

but I'm not sure this is the right solution, or why webpack is looking in the node.js file when the target is set to web.

Suggestions?

EDIT & SOLUTION: I'm using typescript and I overwrote webpack's resolve.mainFields to search for types

  resolve: {
    mainFields: ['main', 'types'],
  },

thus overwriting the default array when targeting a web build (mainFields: ["browser", "module", "main"]) expected by package authors. See docs. Found solution thanks to webpack/webpack-dev-server#727

[thebigredgeek]

This sounds like a bit of a configuration mistake or an error with the bundler. I've used debug personally with webpack (for Node and the browser) and browserify (for the browser). I've never seen issues like this, to be honest. @aryzing I'd love to see your webpack config if you could paste it into a gist and link it here?

[thebigredgeek]

@Rich-Harris did we get a fix merged into the commonjs plugin for webpack? Or is this still outstanding?

[StreetStrider]

@thebigredgeek

I've used debug personally with webpack (for Node and the browser) and browserify (for the browser). I've never seen issues like this, to be honest.

Of course, you've not. Webpack and browserify treat modules in old way, creating IIFE for every module. They do nothing fancy with modules itself. In contrast, Rollup built on principle of module in ES6 sence and a couple of heuristics. That heuristics are creating an issue here. This issue has nothing with webpack or browserify. This topic isn't about webpack or browserify.

[thebigredgeek]

Right, I was responding to @aryzing . I haven't used Rollup, personally, but this seems a bit strange. I am wondering about what @Rich-Harris said about the commonjs plugin?

[krabbypattified]

For me I had warnings for undefined packages native to Node and solved it by shimming the modules :

{
  plugins: [
    commonjs(),
    nodeGlobals(), // required for some shims
    nodeBuildins(), // the shims
  ]
}

[iFwu]

For anyone encounters this error, I have a fix for it.
Just use rollup-plugin-alias and add the following alias to the rollup plugin list:

alias({
  debug: 'node_modules/debug/dist/debug.js',
}),

[Qix-]

This shouldn't be necessary. I use rollup frequently and never run into issues with Debug...

[iFwu]

This shouldn't be necessary. I use rollup frequently and never run into issues with Debug...

If I don't use dist version of debug, the arrow functions in src/browser will not run in IE11.
You can tell that I need to transpile, but when I use babel with typescript and it will cause this issue when compiled to common-js plugin of rollup.

[Qix-]

If I don't use dist version of debug, the arrow functions in src/browser will not run in IE11.

That's not a problem with Rollup. You need to use Babel.

You can tell that I need to transpile, but when I use babel with typescript and it will cause this issue when compiled to common-js plugin of rollup.

This doesn't make any sense. Can you explain, please?

[iFwu]

If I don't use dist version of debug, the arrow functions in src/browser will not run in IE11.

That's not a problem with Rollup. You need to use Babel.

You can tell that I need to transpile, but when I use babel with typescript and it will cause this issue when compiled to common-js plugin of rollup.

This doesn't make any sense. Can you explain, please?

After separating the node and browser build, the problem no longer exists.

[iFwu]

@Qix- I found where the real problem is. It's babel's preset-env. When set preset-env's option loose to true, all errors gone away.

[kopax]

For anyone encounters this error, I have a fix for it.
Just use rollup-plugin-alias and add the following alias to the rollup plugin list:

alias({
  debug: 'node_modules/debug/dist/debug.js',
}),

@iFwu I have the same error and this didn't helped.

Where do you place it? Can we see a sample of your configuration?