Open timbertson opened 8 years ago
Thanks for your information.
I use try catch because if there is an error, i would like this process exit with code 1 so that ruby process will know that the webpack has failed.
Maybe I should get tmpPath from config only and if there is no such option, the plugin should do nothing.
You don't need to explicitly exit the process - any unhandled exception in nodejs will cause the process to exit with non-zero exit status (as well as printing a stacktrace). I took out the try/catch, and for the same failure it now prints a stacktrace and exits with status 1
:
function callback (deps, options) {
var tmpPath = process.env['WR_TMP_FILE'], tmpFile;
deps = deps || [];
if (!tmpPath) {
if (options.webpackrails && options.webpackrails.root) {
tmpPath = path.join(options.webpackrails.root, 'tmp/webpackrails', DEPEN_FILE);
} else {
tmpPath = path.join(process.env['RAILS_ROOT'], 'tmp/webpackrails', DEPEN_FILE);
}
}
tmpFile = fs.openSync(tmpPath, 'w+');
fs.writeSync(tmpFile, deps.join('\n'));
fs.close(tmpFile);
}
The stacktrace includes DepsPlugin.callback (<...>/node_modules/railshot-webpack-plugin/index.js:28:24)
, which is very useful info for anyone else hitting this (or similar) problems.
With this plugin enabled, any attempt to run webpack via its CLI gives:
The error is caused by this plugin using
ENV['RAILS_ROOT']
without checking for its existence, and is then made much harder to debug by thiscatch
which swallows information which would have aided debugging (the stacktrace).It was only by trial and error disabling plugins one-by-one that I figured out which plugin was breaking webpack.