fix: reduce spammy logs

[alexander-akait]

What kind of change does this PR introduce?

bugfix

Did you add tests for your changes?

Existing

If relevant, did you update the documentation?

No

Summary

No need extra logs, please disable them by default, so I change info to log

Does this PR introduce a breaking change?

No

Other information

we should output minimum information, stats is enough by default, developers don't love it

[anshumanv]

need rerun CI after merge - #2208

[anshumanv]

lint fixed in master, we can skip rebase and merge on CI green

[codecov]

Codecov Report

Merging #2206 (b3b203e) into master (53ed926) will increase coverage by 0.34%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #2206      +/-   ##
==========================================
+ Coverage   68.19%   68.54%   +0.34%     
==========================================
  Files          70       70              
  Lines        2352     2378      +26     
  Branches      523      535      +12     
==========================================
+ Hits         1604     1630      +26     
  Misses        748      748              

Impacted Files	Coverage Δ
packages/webpack-cli/lib/plugins/CLIPlugin.js	100.00% <100.00%> (ø)
packages/info/src/index.ts	100.00% <0.00%> (ø)
packages/webpack-cli/lib/utils/cli-flags.js	100.00% <0.00%> (ø)
packages/webpack-cli/lib/utils/arg-parser.js	89.89% <0.00%> (+0.10%)	⬆️
packages/webpack-cli/lib/groups/runHelp.js	99.00% <0.00%> (+0.33%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5872d35...b3b203e. Read the comment docs.

[codymikol]

How can this be turned back on? This actually obfuscated some issues I was experiencing.

[eamodio]

Yeah, I would like to know the same -- as this change breaks problem matcher support in VS Code.

@alexander-akait ?

[alexander-akait]

You should not rely on logger output, it is not safe, but you can enable them using https://webpack.js.org/configuration/other-options/#infrastructurelogging (set level to log)

[eamodio]

@alexander-akait do you have a suggestion on what to rely on then?

[alexander-akait]

stats output with --json flag or --watch-options-stdin

[alexander-akait]

What is use case? Why you need these lines?

[eamodio]

For VS Code problem matchers -- scraping task (terminal) output to report problems, etc.

See:
https://code.visualstudio.com/Docs/editor/tasks#_processing-task-output-with-problem-matchers
https://code.visualstudio.com/Docs/editor/tasks#_background-watching-tasks

[alexander-akait]

In this case please use https://webpack.js.org/configuration/other-options/#infrastructurelogging

[eamodio]

Will that still provide start and stop makers in watch mode?

Also the fact that these are now gone by default adds a lot of extra friction for users since they need a custom config for things to "just work"

[alexander-akait]

Will that still provide start and stop makers in watch mode?

Yes, we just decrease log level

Also the fact that these are now gone by default adds a lot of extra friction for users since they need a custom config for things to "just work"

It is already works fine, I don't know why you use it in this form, most of developers uses scripts and npm run/yarn

Some developers say - please remove extra logs
Some developers say - we need these extra logs

Sorry, I can't solve this problem for everyone

[codymikol]

Will that still provide start and stop makers in watch mode?

Yes, we just decrease log level

Also the fact that these are now gone by default adds a lot of extra friction for users since they need a custom config for things to "just work"

It is already works fine, I don't know why you use it in this form, most of developers uses scripts and npm run/yarn

Some developers say - please remove extra logs
Some developers say - we need these extra logs

Sorry, I can't solve this problem for everyone

I'm totally fine with logs off by default, I was just ignorant as to how to enable them. Your help is much appreciated!

[eamodio]

It is already works fine, I don't know why you use it in this form, most of developers uses scripts and npm run/yarn

I thought I was pretty clear as to what we are/were using it for — allowing VS Code to provide a richer build experience when using built tasks. These tasks can just be (and often are) just package.json scripts run by npm or yarn, or they can have some extra sugar on top to provide more functionality. For example, many devs configure a default build task, and then when they press F5 to start debugging, the debugger waits until the build task completes successfully before launching. Also errors output from typescript/eslint/etc can be scraped and aggregated into the VS Code Problems view:

Also to be clear, I'm only arguing for a start/end marker when in watch, and IMO (even outside the problem matcher issue) not having an end marker at least, doesn't provide a user a nice clear indicator that the watch task has actually completed (especially when you have multiple webpack configs exported)

[alexander-akait]

If you need some extra logs - PR welcome, we don't remove previous logs, just decrease level

[eamodio]

Also, while I can certainly appreciate the you can't please everyone sentiment (and believe me I get it), I am raising this for a community/ecosystem. I am a core dev on VS Code and the maintainer of the webpack typescript/eslint problem matchers.

Yes, I understand that the logs still exist, but we would still like to have the ability to integrate with webpack without a user having to manually alter their configuration -- which was the case before these changes.

[alexander-akait]

@eamodio Can you open a new issue and describe how you run webpack and what you need, I think we can find solution

[eamodio]

@alexander-akait Sorry for the delay, opened it here: #2374