README update - avoid isses related to browser cache during development

[equivalent]

related to hours spent figuring out #90 :)

[dhh]

@brenogazzola We should think about a better solution here. But one does not immediately come to mind!

[brenogazzola]

Since the server is only used in development we could change the cache-control header to no cache or no store for css files. I’ll test it and see what happens.

[brenogazzola]

Ok, to make things clear: The problem is that the digest of the application.js file does not change, even though the digests of the files it includes did change. And because the .digest is also used as an ETAG, even if we use no-cache or no-store, the browser will not redownload.

We have two options:
1 - Calculate the digest of including files after the compiler of the included files are run
2 - Remove the ETAG header and use a no-cache and last-modified header that somehow will notice that the compiled file was modified

I will see about doing one of the two (or maybe something else)

[brenogazzola]

Possible PR to fix this: #96

[brenogazzola]

Closed that one. It's still going to be a problem in production.

[brenogazzola]

I've been testing this our outside of rails, and it seems this is a normal problem with the @import rule. Browsers cache the files and don't notice if you change the @import inside them. I thought they might skip caching or something like that, but no. So we can't cheat and copy their behavior.

All solutions I've tried so far get stuck in one of two:
1 - You need stable fingerprints in production (no cache busting on every deploy)
2 - You might have multiple levels of @import or cyclical @import

[dhh]

Could we simply send no-cache headers in development?

[equivalent]

Yes in fact the no-cache header does the trick ! 🎉. Creating new PR with solution => #124

thx @brenogazzola @dhh

closing this one