Open SetTrend opened 2 years ago
your idea could be useful, but full webpack config really big + there is no way to serialize object
like parameters (plugins objects, functions) correctly
@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
@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.
I think we will move this issue in webpack-cli
repo after we expose some methods from webpack
Sounds great!
Please pardon me for choosing the wrong repo. I was not aware of the other repository.
@alexander-akait:
Would you want to put this improvement request on your roadmap?
You can send a PR, it is already in ROADMAP, but I don't have time on this currenty, sorry
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.
Issue was closed because of inactivity.
If you think this is still a valid issue, please file a new issue with additional information.
@alexander-akait: I believe this issue is still important.
Yeah :+1:
So, this isn't going to be implemented..?
No, but you can help us
@SetTrend Let's put it here, because it is the job of webpack-cli
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.
@SetTrend Don't worry, just the question
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.
*ping*
Do you want the output of this command in the terminal or as an extra file created
I think StdOut is the perfect output channel. The output can be redirected then on demand.
ok working on it
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
why is this error coming everytime
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.
Should I take the config from stdin then?
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
@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
We have them in webpack core there are two function - you can get default value and normalize them
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:
… the proposed Webpack CLI
config
command:… should output the following to
stdout
:**Excerpt only:** ```js 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:
mode
is the only property not being output asundefined
, because it's being defined in the configuration file.mode
is the only property without a default value comment, because no default is applied to it.browserlist
file exists in this example. Then the actual default value for thetarget
property is"web"
, as is depicted in the excerpt above.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 outputundefined
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:
Are you willing to work on this yourself?
no