Gracefully handle missing fingerprinted file

[herschel666]

Hi.

As we've briefly talked about already in Slack, I'm not very fond of the way Architect handles requests to fingerprinted files, that aren't present in the manifest.json's mapping. In case the file could not be found, having the HTML resource, that initiated the request to the static asset, fail with a 500, feels to me like shooting the messenger. Imho only the request of the missing static asset itself should fail — with a 404. The change I made in this PR introduces exactly that.

A drawback of this is, that missing static assets aren't that obvious anymore. On the other hand, this is not uncommon. Hunting down subsequent 404s after page load requires a little effort. I think that's fine.

What do you think?

[brianleroux]

thought about this for a while and I agree; this would be a better behavior… also a breaking change I think so I'll poll other maintainer opinions here. thx for your patience! cc @ryanblock @filmaj

[ryanblock]

Just triaging some old PRs here! There's some overlapping abstractions here that may be confusing the core issue – let's separate HTTP error codes from the method behavior.

Ultimately this method exists to map non-fingerprinted to fingerprinted filenames. If called with a file that doesn't exist, I don't think it should act as though it exists, and pass back a value that may or may not work. I can get there that perhaps throwing is too aggressive, so maybe we should instead just return undefined or null?

[herschel666]

[…] so maybe we should instead just return undefined or null?

That would also be fine.