feat: etag support

[privatenumber]

This PR contains a:

• [ ] bugfix
• [x] new feature
• [ ] code refactor
• [ ] test update
• [ ] typo fix
• [ ] metadata update

Motivation / Use-Case

• Etags: https://github.com/webpack/webpack-dev-middleware/issues/738

Breaking Changes

N/A

Additional Info

Will work on tests tomorrow but opening a PR to get a head start on review and feedback.

[codecov[bot]]

Codecov Report

Merging #746 (420c6fb) into master (1df8477) will decrease coverage by 6.93%. The diff coverage is 14.28%.

@@            Coverage Diff             @@
##           master     #746      +/-   ##
==========================================
- Coverage   99.15%   92.21%   -6.94%     
==========================================
  Files          10       10              
  Lines         236      257      +21     
  Branches       72       78       +6     
==========================================
+ Hits          234      237       +3     
- Misses          2       16      +14     
- Partials        0        4       +4     

Impacted Files	Coverage Δ
src/middleware.js	67.85% <14.28%> (-32.15%)	:arrow_down:

---

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 1df8477...420c6fb. Read the comment docs.

[privatenumber]

As I work on the tests, I'm just realizing that express adds etags by default.

Feels redundant to make it disabled by default on the middleware, and this also makes it difficult to test because etags are on even if the middleware option is disabled.

Do you mind if I make this a PR against https://github.com/webpack/webpack-dev-middleware/pull/747? That way I can pull in the vanilla HTTP version and use connect in the test.

[alexander-akait]

As I work on the tests, I'm just realizing that express adds etags by default.

Yes, we will enable it by default, but we really need a option to disable this

Do you mind if I make this a PR against #747? That way I can pull in the vanilla HTTP version and use connect in the test.

Yes

[alexander-akait]

I studied all the material and other implementation, so I want to implement options:

• cacheControl
• etag
• lastModified

It should be not hard, WIP on this, but I think release will be on the next week only

[alexander-akait]

Anyway thanks for good idea

[privatenumber]

@evilebottnawi

I thought about time-based caching (cache-control/if-modified-since) as well but concluded it wouldn't be as useful as a content-based one (etag) in a rapid development environment.

I imagine it would actually lead to:

• unexpected behavior (changed code not getting immediately fetched)
• users not understanding the feature and disabling caching in the browser
• people turning it off/not using it

[alexander-akait]

I will provide some docs on this to help developers, anyway etag is very easy to implement, so it will be implemented in near future and enabled by default