Troubleshooting

If you get stuck, please try discussing the issue on the Rollup Discord or posting a question to Stackoverflow . If you've found a bug, or Rollup can't meet your needs, please try raising an issue . Lastly, you may try contacting @RollupJS on Twitter.

Avoiding eval ​

You probably already know that ' eval is evil', at least according to some people. But it's particularly harmful with Rollup, because of how it works – unlike other module bundlers, which wrap each module in a function, Rollup puts all your code in the same scope.

That's more efficient, but it means that the shared scope is 'polluted' whenever you use eval , whereas with a different bundler, modules that didn't use eval would not be polluted. A minifier can't mangle variable names in polluted code, because it can't guarantee that the code to be evaluated doesn't reference those variable names.

Furthermore, it poses a security risk in that a malicious module could access another module's private variables with eval('SUPER_SEKRIT') .

Luckily, unless you really do intend for the evaluated code to have access to local variables (in which case you're probably doing something wrong!), you can achieve the same effect in one of two ways:

eval2 = eval ​

Simply 'copying' eval provides you with a function that does exactly the same thing, but which runs in the global scope rather than the local one:

var eval2 = eval;
(function () {
	var foo = 42;
	eval('console.log("with eval:",foo)'); // logs 'with eval: 42'
	eval2('console.log("with eval2:",foo)'); // throws ReferenceError
})();

new Function ​

Using the Function constructor generates a function from the supplied string. Again, it runs in the global scope. If you need to call the function repeatedly, this is much, much faster than using eval .

Tree-shaking doesn't seem to be working ​

Sometimes, you'll end up with code in your bundle that doesn't seem like it should be there. For example, if you import a utility from lodash-es , you might expect that you'll get the bare minimum of code necessary for that utility to work.

But Rollup has to be conservative about what code it removes in order to guarantee that the end result will run correctly. If an imported module appears to have side effects , either on bits of the module that you're using or on the global environment, Rollup plays it safe and includes those side effects.

Because static analysis in a dynamic language like JavaScript is hard, there will occasionally be false positives. Lodash is a good example of a module that looks like it has lots of side effects, even in places that it doesn't. You can often mitigate those false positives by importing submodules (e.g. import map from 'lodash-es/map' rather than import { map } from 'lodash-es' ).

Rollup's static analysis will improve over time, but it will never be perfect in all cases – that's just JavaScript.

Error: "[name] is not exported by [module]" ​

Occasionally you will see an error message like this:

'foo' is not exported by bar.js (imported by baz.js)

Import declarations must have corresponding export declarations in the imported module. For example, if you have import a from './a.js' in a module, and a.js doesn't have an export default declaration, or import {foo} from './b.js' , and b.js doesn't export foo , Rollup cannot bundle the code.

This error frequently occurs with CommonJS modules converted by rollup-plugin-commonjs , this package has been deprecated and is no longer maintained. Please use @rollup/plugin-commonjs .

Error: "this is undefined" ​

In a JavaScript module, this is undefined at the top level (i.e., outside functions). Because of that, Rollup will rewrite any this references to undefined so that the resulting behaviour matches what will happen when modules are natively supported.

There are occasional valid reasons for this to mean something else. If you're getting errors in your bundle, you can use options.context and options.moduleContext to change this behaviour.

Warning: "Sourcemap is likely to be incorrect" ​

You'll see this warning if you generate a sourcemap with your bundle ( sourcemap: true or sourcemap: 'inline' ) but you're using one or more plugins that transformed code without generating a sourcemap for the transformation.

Usually, a plugin will only omit the sourcemap if it (the plugin, not the bundle) was configured with sourcemap: false – so all you need to do is change that. If the plugin doesn't generate a sourcemap, consider raising an issue with the plugin author.

Warning: "Treating [module] as external dependency" ​

Rollup will only resolve relative module IDs by default. This means that an import statement like this…

import moment from 'moment';

…won't result in moment being included in your bundle – instead, it will be an external dependency that is required at runtime. If that's what you want, you can suppress this warning with the external option, which makes your intentions explicit:

// rollup.config.js
export default {
	
entry
: 'src/index.js',
	
dest
: 'bundle.js',
	
format
: 'cjs',
	
external
: ['moment'] // <-- suppresses the warning
};

// rollup.config.js
export default {
	/* ..., */
	
watch
: {
		
chokidar
: {
			
useFsEvents
: false