hard-source-webpack-plugin
hard-source-webpack-plugin copied to clipboard
Failing to build CSS files with error: no such file or directory, open '/srv/.cache-plugin/stamp'
Expected Behavior
Builds should complete without errors when using the hard source plugin.
Actual Behavior
Just this morning, without any change to my Webpack configuration, any dependencies or my project, I've started getting an error for every CSS file that should be output by Webpack. The error references the .cache-plugin folder (which is my configured path for Hard Source to put its files), so I assume this has something to do with the Hard Source plugin. If I remove the hard source plugin, my build works fine.
Failing to build with errors for each CSS file that should be output. For some files, the error is:
ENOENT: no such file or directory, open '/srv/.cache-plugin/stamp'
and for other files, the error is:
ENOENT: no such file or directory, open '/srv/.cache-plugin/version'
Both of those files do actually exist and I can access them as the user running Webpack (both before and after running Webpack).
Is an error being thrown?
ERROR in Error: ENOENT: no such file or directory, open '/srv/.cache-plugin/stamp'
- compiler.js:69 Object.compileTemplate
[srv]/[html-webpack-plugin]/lib/compiler.js:69:10
- index.js:47 Compiler.<anonymous>
[srv]/[html-webpack-plugin]/index.js:47:40
- Tapable.js:293 Compiler.applyPluginsParallel
[srv]/[webpack]/[tapable]/lib/Tapable.js:293:14
- Compiler.js:488
[srv]/[webpack]/lib/Compiler.js:488:8
- Tapable.js:195 Compiler.applyPluginsAsyncSeries
[srv]/[webpack]/[tapable]/lib/Tapable.js:195:46
- Compiler.js:481 Compiler.compile
[srv]/[webpack]/lib/Compiler.js:481:7
- Compiler.js:236
[srv]/[webpack]/lib/Compiler.js:236:10
- Compiler.js:405 Array.<anonymous>
[srv]/[webpack]/lib/Compiler.js:405:11
- CachedInputFileSystem.js:40 Storage.finished
[srv]/[enhanced-resolve]/lib/CachedInputFileSystem.js:40:15
- CachedInputFileSystem.js:77
[srv]/[enhanced-resolve]/lib/CachedInputFileSystem.js:77:9
- graceful-fs.js:78
[srv]/[graceful-fs]/graceful-fs.js:78:16
Steps to Reproduce
I'm not sure how to reproduce as this has just started happening this morning on an unchanged repository. I'm using WSL (Bash on Ubuntu on Windows) and Docker for Windows and running my builds inside a simple Node container:
docker run \
--rm \
-it \
--env "NODE_ENV=development" \
--volume "$(pwd):/srv" \
--workdir /srv \
node:10 \
node_modules/webpack/bin/webpack.js --config webpack.config.js --progress
Replacing the last line above with sh, I can inspect the folder structure in the container before and after running the Webpack command. The files it's failing to access definitely exist and can be accessed by the user running the build.
My Webpack plugins are as follows:
plugins: [
new webpack.DefinePlugin({
DEBUG: 'true',
'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV)
}),
new HardSourcePlugin({
cacheDirectory: path.resolve('.cache-plugin'),
}),
new CleanPlugin(['app-build/*']),
new FaviconsPlugin({
icons: {
android: false,
appleIcon: false,
appleStartup: false,
coast: false,
favicons: true,
firefox: false,
opengraph: false,
twitter: false,
yandex: false,
windows: false
},
logo: path.resolve(appPath, 'image/logo.png'),
prefix: 'image/icon-[hash:8]/',
title: 'App'
}),
new HtmlPlugin({
filename: 'index.html',
hash: false,
inject: 'body',
minify: {
collapseWhitespace: true,
conservativeCollapse: true,
decodeEntities: true,
minifyCSS: true,
minifyJS: false,
preserveLineBreaks: true,
removeComments: true,
removeEmptyAttributes: true,
removeRedundantAttributes: true,
removeScriptTypeAttributes: true,
removeStyleLinkTypeAttributes: true,
sortAttributes: true,
sortClassName: true
},
template: path.resolve(appPath, 'index.html')
}),
new ExtractTextPlugin({
allChunks: true,
filename: '[name].[chunkhash].css'
}),
new CompressionPlugin({
asset: '[path].gz[query]',
algorithm: 'gzip',
test: /\.js$|\.css$|\.html$/,
threshold: 10240,
minRatio: 0.8
}),
new webpack.NamedModulesPlugin(),
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor' // Separate vendor files into a chunk
}),
new webpack.optimize.CommonsChunkPlugin({
name: 'manifest' // Separate Webpack boilerplate into its own chunk
})
]
Operating System, Node, and NPM dependency versions
Windows 10.0.17134
Node 10.4.1
Docker for Windows 18.03.1
{
"dependencies": {
"@fortawesome/fontawesome": "^1.1.4",
"@fortawesome/fontawesome-free-solid": "^5.0.8",
"@fortawesome/react-fontawesome": "^0.0.17",
"babel-plugin-transform-object-rest-spread": "^6.26.0",
"classnames": "^2.2.5",
"fetch-ponyfill": "^4.0.0",
"history": "^4.7.2",
"lodash": "^4.17.5",
"prop-types": "^15.5.10",
"react": "^15.5.4",
"react-breadcrumbs": "^2.1.4",
"react-dom": "^15.5.4",
"react-fileupload-progress": "^0.4.0",
"react-redux": "^5.0.7",
"react-redux-idle-monitor": "^0.3.3",
"react-router-dom": "^4.2.2",
"react-router-redux": "^5.0.0-alpha.9",
"redux": "^3.7.2",
"redux-api-middleware": "^2.2.0",
"redux-idle-monitor": "^0.10.2",
"redux-localstorage": "^0.4.1",
"redux-logger": "^3.0.6",
"redux-thunk": "^2.2.0",
"validator": "^9.4.1"
},
"devDependencies": {
"babel-core": "^6.24.1",
"babel-loader": "^7.0.0",
"babel-plugin-react-css-modules": "^2.7.0",
"babel-preset-env": "^1.4.0",
"babel-preset-react": "^6.24.1",
"cache-loader": "^1.2.0",
"clean-webpack-plugin": "^0.1.18",
"compression-webpack-plugin": "^0.4.0",
"css-loader": "^0.28.1",
"extract-text-webpack-plugin": "^2.1.0",
"favicons-webpack-plugin": "^0.0.7",
"file-loader": "^0.11.1",
"hard-source-webpack-plugin": "^0.5.16",
"html-webpack-plugin": "^2.28.0",
"image-webpack-loader": "^4.0.0",
"style-loader": "^0.17.0",
"url-loader": "^0.6.2",
"webpack": "^2.5.1"
}
}
This is likely some kind of Windows/NodeJS timing or permissions conflict. Other issues for hard-source have been NodeJS's fs bindings in Windows like trying to create a directory and then using it too soon to make files in it or the permissions for the directory or files being weird. First I'd try other recent Node versions and see if that fixes the issue. Or deleting or renaming the cache to see if a fresh directory will help reset permissions.
There are two times these files are interacted with, reading the cache and writing the cache. Error's reading these files are ignored. We could ignore error's writing these files ... but that is probably a bad idea.