feat: enable compress by default

[snitin315]

• This is a bugfix
• This is a feature
• This is a code refactor
• This is a test update
• This is a docs update
• This is a metadata update

For Bugs and Features; did you add new tests?

Yes

Motivation / Use-Case

Enable compress by default

Breaking Changes

Maybe

Additional Info

No

[codecov]

Codecov Report

Merging #3303 (50f200a) into master (88468b6) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #3303   +/-   ##
=======================================
  Coverage   95.55%   95.56%           
=======================================
  Files          34       34           
  Lines        1260     1262    +2     
  Branches      357      358    +1     
=======================================
+ Hits         1204     1206    +2     
  Misses         52       52           
  Partials        4        4           

Impacted Files	Coverage Δ
lib/utils/normalizeOptions.js	100.00% <100.00%> (ø)

---

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 88468b6...50f200a. Read the comment docs.

[alexander-akait]

hm, do you think it should be true by default?

[snitin315]

Yes, I also see it in TODO https://github.com/webpack/webpack-dev-server/projects/1#card-19879364

[anshumanv]

need update docs

[anshumanv]

we run webpack serve right?

[snitin315]

Actually it is script

webpack-dev-server/package.json

Line 32 in 88468b6

"webpack-dev-server": "node examples/run-example.js",

[anshumanv]

looks good then

[alexander-akait]

Let's change it to npx webpack serve in future PRs

[anshumanv]

will take care

[Den-dp]

@snitin315 I thought that reading (and writing) the content served in the memory - is the fastest thing that can be possible.

And adding compression for the in-memory server will only lead to more CPU usage, and may slow down a feedback loop for the developer (longer refresh time).

In theory, after this change, we will pay more CPU load for in-memory content compression, and un-compression (by Express and the browser). 🤔

[alexander-akait]

@Den-dp yes, but in other case HMR and live reloading will be faster because you will get compressed sources, we collect feedback and maybe revisit it, but I think it is better to have fast development env

[Den-dp]

@alexander-akait looks like @sokra also hit a similar problem with enabling compression by default webpack/webpack#13962

[alexander-akait]

it is another problem