last modified fixes

[Fil]

Addresses two issues with #697 :

1. fix for files called from subfolders (e.g. FileAttachment("volcano.json") in javascript/files. The only change for this issue is to add "/" to the path (and fix relevant tests).
2. support lastModified for data loaders

Point 2 is more tricky and might need a bit more thought. At the time when we compute the file reference, the data loaders may have already run or not. We can't look into the future and know when they'll finish running—nor for that matter be sure they'll ever run successfully. If there is a cached filed already, we can't be sure it's going to be fresh or not.

So, this uses a best guess: if the file already has a cached version, lastModified is the date of that cached file. If not, lastModified is currentDate (which is a mock date for unit tests, and the time the process was started for preview and for build).

This best guess is, I think, good enough for preview. However it means that we'll report a file.lastModified that in some cases will be optimistic, because the file might be actually built a few moments (minutes) later. This could be considered as a bug when you build the project and you see that the lastModified time reported in a file is before the time returned by, say, an API call made by the data loader.

I don't worry about that too much, but if we wanted to use the true filemtime of the built assets, we'd need to re-run the build of those pages after all the data loaders have run (if any of them was not fresh), so that on the second run they use the cache and get the correct filemtime. I'm not sure it's worth adding that complexity, in the sense that, if that really matters for your application, you can run yarn build twice. But we could do that, if we decide it's important, or alternatively do some bookkeeping with a list of files where the actual file dates will need to be updated post-data loaders.

Another way of “fixing” this would be to name this property in a more generic way that doesn't imply a contract about the "last modification date". If we called it time, timestamp, ts, or date we could define the contract on our own terms: “ts represents the last time this file was modified or, in the case of data loaders, the last time they ran or were scheduled to run” (or something less verbose).

[mbostock]

Good catches! I’ll need to think about this more so moving to the back burner for a bit.

[Fil]

for point 2 we can use two passes, like we do in #758

will need to rebase on #765 (note: not doing it now, but there is no conflict at this point)

[Fil]

superseded by #1051