image-webpack-loader
image-webpack-loader copied to clipboard
tcoopman
This loader generate many strange files in my project root path
Can you show me your webpack config file? Without it, I have no clue what could be wrong.
On Thu, 18 Aug 2016 at 11:17 luxueyan [email protected] wrote:
How avoid this happens! [image: image] https://cloud.githubusercontent.com/assets/1555552/17768644/816bd3bc-6567-11e6-9820-d35a74ad74c3.png
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tcoopman/image-webpack-loader/issues/41, or mute the thread https://github.com/notifications/unsubscribe-auth/AACx6nS-pXrLjOtFi0LAfIoIV6Zwum65ks5qhCMggaJpZM4JnSnX .
OK! this is my base config for dev environment.
var path = require('path')
var config = require('../config')
var utils = require('./utils')
var projectRoot = path.resolve(__dirname, '../')
module.exports = {
entry: {
app: './src/main.js'
},
output: {
path: config.build.assetsRoot,
publicPath: process.env.NODE_ENV === 'production' ? config.build.assetsPublicPath : config.dev.assetsPublicPath,
filename: '[name].js'
},
resolve: {
extensions: ['', '.js', '.vue'],
fallback: [path.join(__dirname, '../node_modules')],
alias: {
'vux-components': path.join(__dirname, '../node_modules/vux/dist/components'),
'src': path.resolve(__dirname, '../src'),
'assets': path.resolve(__dirname, '../src/assets'),
'components': path.resolve(__dirname, '../src/components')
}
},
resolveLoader: {
fallback: [path.join(__dirname, '../node_modules')]
},
module: {
preLoaders: [{
test: /\.vue$/,
loader: 'eslint',
include: projectRoot,
exclude: /node_modules/
}, {
test: /\.js$/,
loader: 'eslint',
include: projectRoot,
exclude: /node_modules/
}, {
test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
loader: 'image-webpack?bypassOnDebug&optimizationLevel=7&interlaced=false',
include: projectRoot,
exclude: /node_modules/
}],
loaders: [{
test: /\.vue$/,
loader: 'vue'
}, {
test: /\.js$/,
loader: 'babel',
include: projectRoot,
exclude: /node_modules/
}, {
test: /\.json$/,
loader: 'json'
}, {
test: /\.html$/,
loader: 'vue-html'
}, {
test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,
loader: 'url',
query: {
limit: 1000,
name: utils.assetsPath('img/[name].[hash:7].[ext]')
}
}, {
test: /\.(woff2?|eot|ttf|otf)(\?.*)?$/,
loader: 'url',
query: {
limit: 1000,
name: utils.assetsPath('fonts/[name].[hash:7].[ext]')
}
}]
},
eslint: {
formatter: require('eslint-friendly-formatter')
},
vue: {
loaders: utils.cssLoaders()
},
imageWebpackLoader: {
pngquant: {
quality: "65-90",
speed: 4
},
svgo: {
plugins: [{
removeViewBox: false
}, {
removeEmptyAttrs: false
}]
}
}
}
I just noticed this as well, although the hashed file names were appearing in /tmp, instead of the project root. I did a bit of digging, and it seems like this is related to exec-buffer, which is used by many of the imagemin-* processors, not cleaning up the temporary files that it creates for its input and output. It looks like there's a PR open with exec-buffer to fix this at https://github.com/kevva/exec-buffer/pull/4, so that will likely solve things once it gets merged and integrated into the various imagemin processors.
I had almost thrown this loader away until i figured it out. The above is solved by changing the configuration just a little. I don't know why loaders authors assume that everyone has gone through the webpack documentation and understood it.
I did went through it, and understood it once, but to connected the dots between this loader for example and the webpack file-loader as a beginner of webpack, all hell breaks loose.
here is the solution to all those looking for a solution to the above problem.
{
test: /\.(jpe?g|png|gif|svg)$/i,
loader: [
'file?hash=sha512&digest=hex&name=../../assets/images/[name]-[hash].[ext]',
'image-webpack?bypassOnDebug&optimizationLevel=7&interlaced=false'
]
}
notice the issue is at 'file?hash=sha512&digest=hex&name=../../assets/images/[name]-[hash].[ext]' the default is that this loader tells you to do is: 'file?hash=sha512&digest=hex&name=[hash].[ext]'
that creates the extracted image files in the js output folder or root for the above problem. My problem was it was outputting the files in the js folder, as I am using laravel elixir in combination with this image-webpack-loader, it would create hashed names and the original extension in the public/js folder, which exactly what it was told to do: &name=[hash].[ext] notice that there is no folder there.
Then the browser won't find those files as it will be instructed that there was no folder where those files were put, I think it's a webpack loaders issue that needs fixing, therefore it assumes the file to be in the root causing that 404 error.
The journey to solving it, doing something like: &name=images/[hash].[ext] will produce an image like js/images/22492d499f432ca466897f5eb011279e.png, and instruct the browser that the file to load is images/22492d499f432ca466897f5eb011279e.png, which doesn't work again since there is a js top folder.
To actually solve it you put a ../ before images like so: &name=../images/[hash].[ext] which will produce files that match this: images/22492d499f432ca466897f5eb011279e.png and instruct the browser that the file to load is images/22492d499f432ca466897f5eb011279e.png as usual and boom!!! it works. NOTE: I have two ../../ in my original eg coz I have two top folders (js/assets/) to backtrack from to the root where the browser will be starting from.
To completely remove the files from being produced add emitFile=false in the file query string like so:
'file?hash=sha512&digest=hex&emitFile=false&name=../images/[name]-[hash].[ext]'
But I am not sure how you will be able to get the browser to load the file without using url-loader. I think you will have to use url-loader to encode the file as a base64 or something in the file.
I think you are just giving yourself too much work through that avenue though.
By the way this is in the webpack configuration as instructed by the readme of this package. I think this should be clearly stated in the readme to avoid future problems to newbies. I think I will do a PR on it soon.