Add CLI command to output current in-memory configuration in full

[SetTrend]

Feature request

I propose to add a new command to Webpack CLI that outputs a project's current configuration in full detail – including default values.

The output should be a full-fledged JS file, with actual values used for each single configuration property. If no configuration value is provided, the actual and the computed default value should be added in a comment next to the value (which usually is undefined, as it is undefined).

For example, given a configuration like this:

module.exports =
{
  mode: "development",
};

… the proposed Webpack CLI config command:

npx webpack config [config-path [config-name]]

… should output the following to stdout:

Excerpt only:

const path = require('path');

module.exports = {
  target: undefined /* "web" */,
  mode: "development",
  entry: undefined /* "./src" */,
  output: {
    path: undefined /* path.resolve(__dirname, "dist") */ /* "C:\repos\myproject\dist" */,
    filename: undefined /* "[name].js" */,
    publicPath: undefined /* "/assets/" */,

  // ...
  // ...
  // ...

  optimization: {
    chunkIds: undefined /* "size" */,
    moduleIds: undefined /* "size" */,
    mangleExports: undefined /* "size" */,
    minimize: undefined /* true */,
    minimizer: undefined /* null */
  )
}

Please note the following in the above excerpt:

1. mode is the only property not being output as undefined, because it's being defined in the configuration file.
2. mode is the only property without a default value comment, because no default is applied to it.
3. Suppose, no browserlist file exists in this example. Then the actual default value for the target property is "web", as is depicted in the excerpt above.
4. The actual default value for the output.path property is a computation (path.resolve(__dirname, "dist")). This will result in a second comment being added to the property, containing the computed default value, which is "C:\repos\myproject\dist".

What is motivation or use case for adding/changing the behavior?

Although there are many useful default values being applied to Webpack when a small configuration in a Webpack configuration file is used, it's still obscure which actual values are being used for all untouched Webpack configuration properties. So, it's hard to figure out unwanted or less than perfect build behaviour.

Moreover, with the proposed output, GUI tools can be written to provide form based helpers or linters for editing/optimizing webpack configurations.

What is the expected behavior?

A new Webpack CLI command, config, should output a configuration's actual and default values. Values not defined in the config file should output undefined as the property value plus an additional comment added, showing their actual default value. If that actual default value is a computation, a second comment should be added to the output, showing the computed value.

NB: Redirection of the output to a file should be possible.

How should this be implemented in your opinion?

An additional CLI command should be written, resulting in a syntax like the following:

npx webpack config [config-path [config-name]]

Are you willing to work on this yourself?

no

[vankop]

your idea could be useful, but full webpack config really big + there is no way to serialize object like parameters (plugins objects, functions) correctly

[alexander-akait]

@vankop in theory we can export https://github.com/webpack/webpack/blob/main/lib/config/normalization.js#L528 and output default values, functions/classes/etc will be outputed as serialized

[SetTrend]

@vankop: Yes, you are right. I expect the output to be large. In my vision, the main target of this output are supposed to be linters and external tools, not human beings.

But actually, an optional, additional parameter to the proposed Webpack CLI command could be used to filter the output, e.g.:

npx webpack config [[--file ]config-path] [--name config-name] [--include included-properties]

… so, given the following existed …

npx webpack config --include output,cache

… the output could be similar to:

module.exports = {
  output: {
    library: {
      name: 'someLibName',
      type: undefined /* this */,
      // ...
    },
    filename: 'someLibName.js',
    auxiliaryComment: undefined /* null */,
    // ...
  },
  cache: {
    type: 'filesystem',
    allowCollectingMemory: true,
    version: undefined /* null */,
    // ...
  },
};

… having only two properties and their values included.

[alexander-akait]

I think we will move this issue in webpack-cli repo after we expose some methods from webpack

[SetTrend]

Sounds great!

Please pardon me for choosing the wrong repo. I was not aware of the other repository.

[SetTrend]

@alexander-akait:

Would you want to put this improvement request on your roadmap?

[alexander-akait]

You can send a PR, it is already in ROADMAP, but I don't have time on this currenty, sorry

[SetTrend]

Perfect. I was just asking you because the webpack-bot was about to close this issue. Unfortunately I cannot afford the time to contribute at this time, though I'd very much liked to do so.

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

[SetTrend]

@alexander-akait: I believe this issue is still important.

[alexander-akait]

Yeah 👍

[SetTrend]

So, this isn't going to be implemented..?

[alexander-akait]

No, but you can help us

[alexander-akait]

@SetTrend Let's put it here, because it is the job of webpack-cli

[SetTrend]

Unfortunately I cannot help. I'm currently working for a bluechip customer with a tight deadline. I'm not able to lift further workload, I'm afraid.

[alexander-akait]

@SetTrend Don't worry, just the question

[webpack-bot]

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.

[SetTrend]

*ping*

[samrudh3125]

Do you want the output of this command in the terminal or as an extra file created

[SetTrend]

I think StdOut is the perfect output channel. The output can be redirected then on demand.

[samrudh3125]

ok working on it

[samrudh3125]

async showConfig(){
const config=await fs.readFileSync(path.resolve(process.cwd(), "webpack.config.js"), "utf-8");
return config;
}
I have created a function here what should be the return type here since I didnt understand the types.ts completely

[samrudh3125]

why is this error coming everytime

[SetTrend]

From what I can see from your code, you are reading from the webpack.config.js file. My request was to read the current in-memory configuration. Eventually the configuration that's active when there is no webpack.config.js file.

[samrudh3125]

Should I take the config from stdin then?

[samrudh3125]

I have completed the coding part should I delete the builtInOptions -c and --config-name?
Also what will be the difference between --config-name and --include

[samrudh3125]

@alexander-akait I have done all the coding jobs I just need a sample file or an api from where I can load all the options along with their default values

[alexander-akait]

We have them in webpack core there are two function - you can get default value and normalize them

[SidSingh11702]

The output should be a full-fledged JS file

@SetTrend Can you please update the ask here based on this reply

[SidSingh11702]

From what I can see from your code, you are reading from the webpack.config.js file. My request was to read the current in-memory configuration. Eventually the configuration that's active when there is no webpack.config.js file.

@SetTrend Can you mention about this in the issue description.

A new Webpack CLI command, config, should output a configuration's actual and default values. Values not defined in the config file should output undefined as the property value plus an additional comment added, showing their actual default value. If that actual default value is a computation, a second comment should be added to the output, showing the computed value.

This seems to mean that the configurations are to be read from the file (webpack.config.js)

[SidSingh11702]

Hi @SetTrend, can you please respond to the above queries. Below two statements seem conflicting to me.

From what I can see from your code, you are reading from the webpack.config.js file. My request was to read the current in-memory configuration. Eventually the configuration that's active when there is no webpack.config.js file.

This mentions about reading from the memory, not sure how it will be fetched.

A new Webpack CLI command, config, should output a configuration's actual and default values. Values not defined in the config file should output undefined as the property value plus an additional comment added, showing their actual default value. If that actual default value is a computation, a second comment should be added to the output, showing the computed value.

This mentions about reading from the "config file" (I believe it is webpack.config.js)

[SidSingh11702]

@snitin315 In case you have idea, can you please clarify.

[SetTrend]

Hi @SidSingh11702, sorry for my late reply.

I am by no means sure how to retrieve the current Webpack in-memory configuration.

Maybe it's the output of parsing the compiler's options variable:
https://github.com/webpack/webpack/blob/644f1d12716ba8f3c96d2efa279262560dd8c7fb/lib/Compiler.js#L285

[SidSingh11702]

The output should be a full-fledged JS file

@SetTrend Can you please update the ask here based on this reply

@SetTrend Can you clarify on this also (and maybe update the issue description). Upon executing the new command, the output should be written to a file or STDOUT?

[SetTrend]

It should be written to StdOut. The user may then interactively redirect the output to any file on demand.