Snowpack: ETAG Support

[FredKSchott]

Original Discussion: https://www.pika.dev/npm/snowpack/discuss/287
/cc @matthoffner, @FredKSchott

Currently, each file requested from the dev server is served. But, if we wanted to be even faster, we could implement etag support: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag

We already have some of the pieces in place here, but we would just need to start returning that hash to the client as a header. We could even get rid of our in-memory build cache, and just store these hashes instead.

• [X] PR 1: Send an etag header with every response, that matches the response body
• [x] PR 2: If the etag matches the hash of the build that we have cached, send back a 304.
• [ ] PR 3: Investigate: can we replace our in memory cache file contents with just the etag value?

Edit: In thinking more about this, I'm worried that completely removing the file contents from the in-memory cache might be too much. Most browsers set "disable cache" when you have the devtools open, which would mean that every browser refresh would rebuild every file, every time. The in-memory cache should be small for a web project, so I don't think it even buys us much.

[stramel]

Looks like we're already generating ETags for cacache. Though those are for the original file, not the output file?

[FredKSchott]

Yup, we knew this would needed eventually so we already use etag for how we hash the persistent build cache. The next step would just be to use that same etag for the in-memory data store as well.

[stramel]

Alright I might take a stand at this tonight

[FredKSchott]

Awesome! check out my edit, I think I may have gone too far to say we could completely remove the in-memory cache just yet, but definitely worth investigating.

[stramel]

I started looking into part 3 of this issue, however, I'm a bit unsure about all the HMR stuff. My initial thoughts are that we more than likely will be able to swap the file contents for an ETag.

[FredKSchott]

Yea, I also just realized that the etag function takes a fraction of a millisecond, even on large files. I think this is fine to keep discussing but I'm going to consider the major parts of this as done, and close this prioritized issue.

Thanks for your work on this @stramel