fix: warn about merge config resolution cases

[anshumanv]

What kind of change does this PR introduce?

fix

Did you add tests for your changes?
Yes

If relevant, did you update the documentation?
NA

Summary

• Right now if merge config is absent, no feedback is given to user when it's absent or when we fallback to default merge config, fix it

Does this PR introduce a breaking change?
No

Other information

[alexander-akait]

Looks good, but I think we should discuss about configuration files. We have webpack.config.development.js, we have webpack.base.js, we have configurations from .webpack directory. It can be very misleading for developers.

We should provide clear and logical hierarchy structure.

Maybe we should not fallback to webpack.base.js here. Just throw an error what we don't find the configuration, because it can be misleading for developers too

[anshumanv]

Maybe we should not fallback to webpack.base.js here. Just throw an error what we don't find the configuration, because it can be misleading for developers too

Agree, but .base is usually used to keep shared config for prod and dev env, which is eventually merged with the respective config hence this fallback was added in past I think, we're already notifying user in case we fallback, what do you think? @evilebottnawi

[alexander-akait]

@anshumanv Do we have this logic for v3?

[anshumanv]

@anshumanv Do we have this logic for v3?

No, we don't. Should we remove fallback?

[rishabh3112]

I think we shouldn't fallback as well, Developer never intends to use .base config as a standalone configuration.

[alexander-akait]

@anshumanv Let's discuss about it. What configuration files do we have and how are they inherited and them priorities? Maybe we can do simple drawing/picture?

[anshumanv]

Developer never intends to use .base config as a standalone configuration.

Using as standalone is out of the picture

[anshumanv]

@anshumanv Let's discuss about it. What configuration files do we have and how are they inherited and them priorities? Maybe we can do simple drawing/picture?

Yep we can, I'll come up with it in a while 👍

[anshumanv]

[
    'webpack.config',
    'webpack.config.dev',
    'webpack.config.development',
    'webpack.config.prod',
    'webpack.config.production',
    '.webpack/webpack.config',
    '.webpack/webpack.config.none',
    '.webpack/webpack.config.dev',
    '.webpack/webpack.config.development',
    '.webpack/webpack.config.prod',
    '.webpack/webpack.config.production',
    '.webpack/webpackfile',
]

@evilebottnawi this the order of priority of files, in increasing order of priority.

eg if webpack.config.* is present and .webpack/webpackfile.* are present, then webpackfile will be resolved during config lookup as it has max priority while webpack.config.* has least priority in this list

We do not resolve for .base while config lookup, hence I think that was added as a fallback file for merge strategy when the supplied config in the merge flag doesn't exist.

[anshumanv]

Also, should we document it somewhere for future reference, it's present in code only for now.

[alexander-akait]

I think we should change logic for this, it is the interesting case, when I use

webpack --config' './1.js', '--config' './2.js

I would think that we want to run both configurations, like multi compiler mode.

But, if i write

webpack --merge --config' './1.js', '--config' './2.js

I want to merge configurations.

I think this logic is simpler and clearer.

If configuration doesn't exists in --config we should always throw an error.

Also provide --config options disable auto resolving configurations, because I have clearly indicated that I want to use.

And yes we should documented configurations and their priority

[anshumanv]

I think we should change logic for this, it is the interesting case, when I use

webpack --config' './1.js', '--config' './2.js
I would think that we want to run both configurations, like multi compiler mode.

But, if i write

webpack --merge --config' './1.js', '--config' './2.js
I want to merge configurations.

I think this logic is simpler and clearer.

If configuration doesn't exists in --config we should always throw an error.

Also provide --config options disable auto resolving configurations, because I have clearly indicated that I want to use.

And yes we should documented configurations and their priority

@evilebottnawi that makes sense, there are a several steps involved to achieve that, let's do them bit by bit.

I'll start by removing the fallback to base config from here, just the error message that the merge config is not found should be good for now.

[anshumanv]

@evilebottnawi are there any cases when the user only wants to merge to one config and use another as is?

Eg - webpack --config webpack1.config.js --config webpack2.config.js --merge webpack.base.js

In this case the user only intends to merge base config with webpack2.config.js, are such cases possible?

[alexander-akait]

Eg - webpack --config webpack1.config.js --config webpack2.config.js --merge webpack.base.js

I don't think we should support is, because it is misleading, if you want to more three configuration, you can use

webpack --config webpack1.config.js --config webpack2.config.js --config webpack.base.js --merge

If you want to run 3 configuration:

webpack --config webpack1.config.js --config webpack2.config.js --config webpack.base.js --merge

If you want to merge first and second configurations, use code for this, no need handle very complex logic

[anshumanv]

If you want to merge first and second configurations, use code for this, no need handle very complex logic

Seems fair @evilebottnawi , I've dropped the support for fallback to default config in merge here, will add support for multi config after this. 👍

[alexander-akait]

Let's override the other option, for example filename, too

[anshumanv]

added 1fdf2ae 👍