Proposal: how to enable long-term caching of assets. about react-server HOT 9 CLOSED

YAWP

😆 ... 😂 ... 😢

from react-server.

We actually implemented something like this internally that sounds similar to option 2. We have a roughly five line webpack plugin that outputs a file called assetsByChunkName.json that we use to tell the server about the entrypoints. For lazy-loaded JS bundles, webpack keeps its own mappings internally, and just knows what files to load. AFAIK, we don't use the assetsByChunkName.json file on the client at all. (cc @bartkusa, who worked on this originally)

from react-server.

Thanks, @roblg!

For lazy-loaded JS bundles, webpack keeps its own mappings internally, and just knows what files to load.

FYI, the Medium article I linked to above explains that this is not enough to keep the hashes constant from build to build; any change to any module changes all the hashes of all entry chunks, even if the entry chunk doesn't include that module. You have to use ChunkManifestPlugin as well; see the section on "Deterministic Hashes".

Any thoughts on using HTTP(S) to download a manifest when the client build is being served up by another server?

from react-server.

Interesting. We definitely expected to have issues w/ non-deterministic behavior, and looked for it, and didn't find it. Although I think we were worried about hashes changing for no reasons. Maybe they all change if any file changes? I don't recall if we checked for that (but @bartkusa may remember).

There's a comment from sokra on the issue linked in the blog post saying that occurrence order is the default. (And then some comments from people after that saying they're still experiencing the issue, though maybe in very particular circumstances.) So maybe it's fixed, maybe not? If we can get away with not adding a dependency on YAWP (Yet Another Webpack Plugin), that would be my preference. IME, the more plugins you have in the build, the more bugs you find in plugins in the build. :)

In any event, to answer your actual question: I don't think see a problem with downloading the file from the static content server at startup.

Alternatively, what's preventing us from just outputting the file in the frontend build, and then having that file copied into the server deploy tar or whatever as a step outside r-s-c? Just convenience?

from react-server.

Although I think we were worried about hashes changing for no reasons. Maybe they all change if any file changes?

Yeah, this issue is not about non-determinism from one build to the next when the code doesn't change. It's about a small code change changing all hashes for all chunks, including completely unrelated ones. To quote the article:

The problem with this is the same as before: whenever we change any part of the code, it will, even if the rest of its contents wasn’t altered, update our entry chunk to include the new manifest.

The problem is that every entry chunk keeps a map of all chunk names, which of course includes the chunk hashes in the chunk names. So, when any chunk changes, its hash changes, which means that the chunk name map changes, which changes the text of the entry chunk, which changes the entry chunk's hash. Yay.

There's a comment from sokra on the issue linked in the blog post saying that occurrence order is the default. (And then some comments from people after that saying they're still experiencing the issue, though maybe in very particular circumstances.) So maybe it's fixed, maybe not?

Occurrence order is a different problem, which can cause hashes to change between different builds of the same codebase. You also need the OccurrenceOrderPlugin (which also is in the linked article).

In that thread, sokra says it's on by default in the next major version (i.e. webpack 2), which is confirmed in this webpack 2 feature list.

what's preventing us from just outputting the file in the frontend build, and then having that file copied into the server deploy tar or whatever as a step outside r-s-c?

I'm trying to decide what to do when react-server-cli is used to build the client code separately from starting up the HTML server, as described here in the docs. I suppose those instructions could be changed to say something like "step 2.5: Copy manifest.json to your server somewhere" and then "step 3: when you start up the HTML server, pass the manifest file in at the command line using --manifest=location/of/manifest.json along with jsUrl". Is that what you mean?

from react-server.

re: determinism - Le sigh. I suppose we probably have a bug to fix now internally as well.

I suppose those instructions could be changed to say something like "step 2.5: Copy manifest.json to your server somewhere" and then "step 3: when you start up the HTML server, pass the manifest file in at the command line using --manifest=location/of/manifest.json along with jsUrl".

Yep, that's what I was thinking. That's basically what we do today internally. I'm assuming that there should be another step somewhere in there that's like "copy your server code to <not the static file server>" as well, right? I would think it would go along with that.

from react-server.

@aickin - Was this covered by #96, or is there more you'd like to see done here?

from react-server.

Sorry, yeah, I think this is covered. Closing!

from react-server.

Thanks!

from react-server.