Consider erroring/warning when static file paths are specified but not found

[humphd]

trafficstars

I ran into an issue yesterday where I specified what I thought were all my static paths for a site, but had typos in 6 of them. Even when passing verbose: true, the caching process silently skips missing paths, thus forcing you to debug it at runtime vs. build. For me, I'd rather know at build time that some of my paths are wrong, and files couldn't be found. So you might have something like:

Caching static resource "dist/extensions/default/bramble-move-file/images/folder-icon-white.svg" (990 B)
Missing static resource "dist/extensions/default/bramble-move-file/images/folder-icon-white.png"

And perhaps a way to optionally have the command fail on missing files.

[jeffposnick]

Strictly speaking, even if you pass in a full path to a single file without any wildcards, the code will still interpret that as a glob pattern.

It sounds like what you're asking for is a warning when there's a specific glob pattern that's used in the configuration, but matches 0 files. Does that sound about right?

[humphd]

I think at the point where you're stat'ing and/or trying to read the file, and it's not there, it would be great if that warned or (optionally) caused the whole thing to fail. I realize doing this via glob isn't going to solve it, but within the lib itself perhaps.

[jeffposnick]

What's going on within the library is:

1. It takes the array of glob patterns from staticFileGlobs. (There's no way to specify a static file path, only a pattern which matches static files.)
2. For each glob pattern, it gets the list of files that match.
3. For each file that matches, it gets some info about the file.

I think this is where you're saying the library should issue a warning if the file isn't found at step 3, but my point is, the way the code is structured, you should never get to step 3 for a file that doesn't exist. (Modulo some improbable race condition.) The library could, potentially, start issuing a warning if there are 0 matches for a given pattern in step 2.

[humphd]

I see. Yes, probably having an option to warn/fail if a glob pattern returns zero results would do it. I get that it's correct for ['some/file.txt'] to not match anything, but it's also surprising if you think you're populating a complete list, and end up missing a bunch of things.

[jeffposnick]

One of the things that makes a lot of the service worker example code "in the wild" brittle is that it invariably includes a big array at the top in which you list every local resource that you want cached. Overtime, the list of resources might change and you could end up forgetting to add or remove file path strings from that array.

With sw-precache, the idea was to encourage developers to think in terms of glob patterns with wildcards that will automatically evolve over time as files are added or deleted from the local development environment. I obviously can't stop developers from using globs without wildcards which effectively look like file paths, and it's understandable if there's a single file in a directory full of other files that shouldn't be precached. But it's not the ideal use case.

[humphd]

Maybe putting your comment above into the docs for staticFileGlobs would help? I agree about the ideal being to just point sw-precache at a dir and slurp up the entire thing with /**/*. That would be great, but it's impossible in my case without forcing the user to cache all kinds of optional bits of the app that aren't really necessary for it to run.

At any rate, sw-precache is great, and it let me put my fork of the Brackets editor into an offline cache that let's users work without network--how cool is that? My comment comes from being surprised as a regular user who read your docs and did what seemed obvious. As you point out, out in the wild where people like me are working with not-ideal-cases, I suspect others will be confused like I was.

[jeffposnick]

Absolutely. And thanks for the feedback, and I'm glad you've found it useful!