What is the current behavior?
Webpack tries to load webpack.config.coffee first when both webpack.config.coffee and webpack.config.js are present. As a result we'll get a syntax error in case we have no coffeescript dependency installed.
If the current behavior is a bug, please provide the steps to reproduce.
Put webpack.config.coffee, configure File Watcher for .coffee file type, get corresponding compiled webpack.config.js, run webpack --mode=production
What is the expected behavior?
It should try to load webpack.config.js first (in case if user just compiles his .coffee config into .js and does not want to install additional coffeescript dependency into his project). Only if there's no .js config file then try to use .coffee.
Other relevant information:
webpack version: 4.35.0
Node.js version: 8.11.1
Operating System: Windows 7
Additional tools: JetBrains WebStorm
How do you load configuration? Are you using node API or webpack-cli or custom script?
I'm using "npm run build" configured in WebStorm where build script is defined in package.json:
"scripts": {
"build": "webpack --mode=production",
}
The same result I get if I try execute in terminal:
webpack --mode=production
Despite both configs .coffee and .js are present it gives error (in case there's no coffeescript installed):
...\webpack.config.coffee:1
(function (exports, require, module, __filename, __dirname) { webpack = require 'webpack'
SyntaxError: Unexpected string
Where you find documentation what we support .coffee configuration?
Please read https://coffeescript.org/#nodejs-usage
I guess I saw that here:
https://github.com/webpack/webpack/issues/475
https://github.com/webpack/webpack/pull/956
So why does webpack binary try to read wepack.config.coffee at all then?
Also I believe someone already encountered similar problem:
https://github.com/webpack/webpack/issues/4639
But the issue is priority, not requirements. Where am I getting it wrong?
Stop writing coffeescript!
Anyway this is an webpack-cli thing, so I'll move it there
First
I think this is the only file which should always be in
.jsthat's it !.
Now Workaround
you can do it
webpack.config.coffee in your webpack.config.js with proper coffee loadercoffee.webpack.config.js (weird naming btw)"build": "webpack --mode=production --config webpack.config.js && webpack --mode=production --config coffee.webpack.config.js ",
I am assuming this is build script, you dont want anything in watch mode, if you want then use some other library like concurrently
OR
manually compile the .coffee to .js and use it
Why do I use .coffee and file watchers. Well because it's very handy. I have global file watchers configured for all my projects and I do not need to switch my mind between .js and .coffee syntax no matter what I do.
Yes there are workarounds, I admit that. But still it would be cool to have correct load priority (I believe it is something very easy to fix actually).
For now I just have coffeescript dependency installed and that solves my problem but still... This is a workaround.
I think this is the only file which should always be in
.jsthat's it !.
Not agree. Because if you use coffee, you don't want to make config.js, you want to make config.coffee which will be compiled into .js automatically.
We need to fix this in v4, discarding coffeescript
@jhnns do you think it's worth supporting coffeescript, or should we choose some set of ext we support?
@evenstensberg you can let https://www.npmjs.com/package/rechoir & https://www.npmjs.com/package/interpret do the heavy lifting. They are battle tested.
We're doing that in the old upstream (master), I think problem was that people started beginning to worry about the size of the dependencies we were having. I'm +1 for having interpret still
How does it work without interpret?
You'll need to have the same functionality either way, interpret has an object with matching ext + paths to a configuration, meaning we won't need to create an object with that ourselves
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
Issue was closed because of inactivity.
If you think this is still a valid issue, please file a new issue with additional information.
Most helpful comment
We're doing that in the old upstream (master), I think problem was that people started beginning to worry about the size of the dependencies we were having. I'm +1 for having interpret still