Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot use debug with Rollup #468

Closed
StreetStrider opened this issue Jun 10, 2017 · 20 comments · Fixed by #507
Closed

Cannot use debug with Rollup #468

StreetStrider opened this issue Jun 10, 2017 · 20 comments · Fixed by #507

Comments

@StreetStrider
Copy link

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
Copy link
Contributor

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
Copy link
Author

@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
Copy link

@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: rollup/rollup-plugin-commonjs#204

@StreetStrider
Copy link
Author

@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
Copy link
Author

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
Copy link

wildeyes commented Aug 6, 2017

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
Copy link

aryzing commented Aug 22, 2017

[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
Copy link
Contributor

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
Copy link
Contributor

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

@StreetStrider
Copy link
Author

@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
Copy link
Contributor

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
Copy link

krabbypattified commented Dec 12, 2018

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
Copy link

iFwu commented Jan 13, 2019

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-
Copy link
Member

Qix- commented Jan 13, 2019

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

@iFwu
Copy link

iFwu commented Jan 13, 2019

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-
Copy link
Member

Qix- commented Jan 13, 2019

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
Copy link

iFwu commented Jan 17, 2019

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
Copy link

iFwu commented Jan 18, 2019

@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
Copy link

kopax commented Sep 29, 2019

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?

@kettanaito
Copy link

@kopax That code should be placed in the plugins property of your Rollup configuration. Here's an example:

import alias from '@rollup/plugin-alias'

module.exports = {
  plugins: [
    alias({ debug: 'node_modules/debug/dist/debug.js })
  ]
}

Note that at the present debug doesn't have such entry. Inspect the built version of debug to provide the correct alias path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.