Issue with npx / node and resolve in config file
DanielRuf opened this issue · 6 comments
I'm submitting a...
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:
Current behavior
When I have outputPath: path.resolve(_dirname, './dist'), in the config template webpack creates the files in the plugin config dir instead of in the project.
outputPath: path.resolve(process.cwd(), './dist'), seems to solve this.
Not sure if I am doing something wrong or if it is a bug in the used loader.
I use image-webp-loader and the following config:
module: {
rules: [{
test: /\.(png|jpe?g)$/i,
use: [{
loader: require.resolve('image-webp-loader'),
options: {
publicPath: '/',
outputPath: path.resolve(_dirname, './dist'),
name: 'images/[name].[hash].[ext]',
requestWebp: true
}
}],
}, ]
},
And I use the following command for local testing:
npx webpack --plugin ../../ue-webpack-config-plugins/packages/webp-config-webpack-plugin
Expected behavior
The webp file should be in the project directory not in the plugin config directory.
Minimal reproduction of the problem with instructions
Fork https://github.com/DanielRuf/ue-webpack-config-plugins/ and use the webp-config-webpack-plugin branch.
What is the motivation / use case for changing the behavior?
Environment
Plugin version: X.Y.Z
- Node version: 10.12.0
- Platform: Windows
Others:
scoop and nvm as package managers.
Don't you think it should rather be part of the https://github.com/namics/webpack-config-plugins/tree/master/packages/image-config-webpack-plugin instead of an individual plugin?
It looks like image-webp-loader is in a very early stage (they have even typos in the plugin name on their readme).
A short look into their code reveals that they use a hardcoded output directory:
Also the image-webp-loader would not work in most projects as it just generates an additional file which is never linked anywhere. If you have for example the following css: body { background: url('back.jpg') } it will still tell the browser to download the jpg no matter if you add the webp loader or not.
Personally I would not add it to the image plugin but as a separate plugin using sharp / libvips.
Also this was just a quick example to test how fast we can add another plugin (had to change many files, would be good to have a template / bootstrap command).
The loader that I have used was the first that I found and tried for this example.
My initial question is still valid, is the path issue a bug in the loader or in the implementation of path resolvement?
Also as far as I understand what you've linked are the fallbacks which are also used by webpack.
Please let us focus on the initial problem =)
As I said before the bug is in the loader:
path.resolve(__dirname, '../../dist')
This means it resolves the path relative to node_modules/image-webp-loader/ - __dirname is not the same as process.cwd()
Please add some console.log statements to the loader
Mh, but __dirname is also the default in your packages, webpack uses the exact same resolve config internally.
So you would say it is a bug in the loader? Because I also tried to set it to the same in our config (the oackage) and it also resolved to the wrong path.
I'll test it with one of your other packages later too to see if this is a webpack or Node.js resolve issue.
Because I think it is an issue with npx and webpack when using paths instead of package names which resolve differently probably.
npx webpack --plugin ../../
I did a test with another package and it seems to be directly caused by __dirname on this level instead on the level of webpack.
So far I can not reproduce this with the other packages.