Plugin: rollup-plugin-commonjs
Plugin Version: 10.1.0
Rollup Version: 1.27.2
Operating System (or Browser): Windows 10
Node Version: 12.13.0
Reproduction steps are outlined in this reduced test case repo:
https://github.com/Dan503/BUG-rollup-plugin-node-resolve/tree/CommonJS-bug
Note this part of gulpfile.js in particular:
const rollupJS = (inputFile, options) => {
return () => {
return (
rollup({
input: options.basePath + inputFile,
format: options.format,
sourcemap: options.sourcemap,
plugins: [
CommonJS(), // <<-- This is the line that calls rollup-plugin-commonjs
],
})
.pipe(source(inputFile, options.basePath))
.pipe(buffer())
.pipe(sourcemaps.init({ loadMaps: true }))
.pipe(sourcemaps.write('.'))
.pipe(gulp.dest(options.distPath))
)
}
}
It should not error.
It throws this error when trying to run the code:
TypeError: Cannot read property 'resolve' of undefined
at resolveId (C:\xxx\node_modules\rollup-plugin-commonjs\dist\rollup-plugin-commonjs.cjs.js:157:17)
at C:\xxx\node_modules\rollup-stream\node_modules\rollup\dist\rollup.js:1750:32
at processTicksAndRejections (internal/process/task_queues.js:93:5)
@Dan503 thanks for opening an issue. Was this one that was a problem with the old rollup-plugin-commonjs as well?
Yes, this is just a copy of the following issue from the old repo:
This looks like it's a problem with rollup-stream and/or use within gulp. I tested that by creating a rollup.config.js file and running rollup directly with npx rollup -c. Here's the config file I used:
// note that I'm using the scoped package here
const CommonJS = require('@rollup/plugin-commonjs');
export default {
input: 'src/main.js',
output: {
format: 'iife',
file: 'dist/main.js'
},
plugins: [CommonJS()],
sourcemap: true
};
When I use that, the build succeeds without issue. Given that the last time it was published was 2 years ago, this isn't really surprising that there's a conflict. It's using a really old version of Rollup too: https://github.com/Permutatrix/rollup-stream/blob/master/package.json#L24, even though you have a recent version in package.json.
For moving forward, it's always a good idea to break out a separate config and run rollup separately. I'd suggest reporting this to rollup-stream, but it's not likely to get traction. I've made an offer to the owner to transfer it to the Rollup org where we could maintain it, so we'll see how that's received. I'm sorry that we couldn't help you resolve this one, but there's nothing we can currently do in rollup plugins or core.
When I use that, the build succeeds without issue.
Could you please make a pull request against the example repo with the work-around solution implemented?
When trying to use existing documentation, it's impossible to get rollup to understand common js if run through Gulp.
Having a working example of how to get it to work would help a lot. ๐
I don't think a PR is necessary in this case. Simply copy that code block, create rollup.config.js in the root, and paste that code block in it. Then run npx rollup -c in your terminal. You'll see the build succeed. That's not so much a workaround as it was a triage proof to show that it wasn't Rollup, nor the commonjs plugin, was at fault there.
Thanks, by the way, this bug is probably related to the same issue: #68
I've created a branch on the repo with instructions on how to fix the issue in Gulp:
https://github.com/Dan503/BUG-rollup-plugin-node-resolve/tree/work-around-solution
The key is to use Gulp only as a means for running Rollup while Rollup handles all the file transformations.
This is what the new Gulp file looks like:
const gulp = require('gulp')
const { exec } = require('child_process')
gulp.task('rollup', done => {
exec('npx rollup -c', (error, stdout, logInfo) => {
console.log(logInfo)
done(error)
})
})
child_process is native to Node and doesn't need to be npm installed.
The downside to this work-around though is that you loose the ability to cache the compiled result so compile times will be significantly increased.
It would be better if rollup-stream could be maintained by the core Rollup team. ๐
I've also found several more up to date forks of rollup-stream that appear to work. This one has been updated for Rollup 1.x, even though it does use a hard dependency. It should probably work. https://github.com/Mazrog/rollup-stream
@Dan503 I've put together https://github.com/rollup/stream that can be used as a git dependency (for the time being - it needs to be reviewed before publishing). It's a basic stream implementation that is valid with latest versions of Rollup, and doesn't have a direct dependency on any one version of Rollup. rollup-stream has a number of forks, all of which are imperfect, and the code for rollup-stream itself couldn't be used large in part anymore, so a rewrite from scratch was necessary. If you have feedback, please share it on the rollup/stream repo.
Awesome, thanks for making an official fork ๐