Webpack-cli: [BUG]: Wrong priority in picking config file between .coffee and .js

Created on 30 Jun 2019  路  17Comments  路  Source: webpack/webpack-cli


Bug report




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

Bug enhancement inactive

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

All 17 comments

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?

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 .js that's it !.


Now Workaround
you can do it

  • add webpack.config.coffee in your webpack.config.js with proper coffee loader
  • this should output to something like coffee.webpack.config.js (weird naming btw)
  • in the build command ,
"build": "webpack --mode=production --config webpack.config.js && webpack --mode=production --config coffee.webpack.config.js ",
  • enjoy ?

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 .js that'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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

r00nscapenab picture r00nscapenab  路  4Comments

sumukhah picture sumukhah  路  3Comments

AjayPoshak picture AjayPoshak  路  5Comments

Pomax picture Pomax  路  3Comments

snitin315 picture snitin315  路  5Comments