Warn if `files` doesn't resolve to a file

[appsforartists]

files leaves room for subtle mistakes that are hard to catch at review time, such as:

      "files": [
        "vite.config.js", // maybe the actual extension is ts
        "../../vite.config.common.ts" // maybe there's a wrong number of ../s

If a literal path is specified that doesn't match an actual file, Wireit should throw an error.

See also #215

[rictic]

This seems like a good default, as it's usually an error, but I wonder about cases where a file might or might not be present, but it's still an input. We'd need a way to express that

[appsforartists]

Good point.

I wonder if letting the last character be ? is close enough. If the last character is ? and there's no file that matches that (which I can't imagine anyone doing on purpose, but it is possible), strip the ? and look for that file.

If a string contains a * or a ?, don't warn if it doesn't find a match. Otherwise, do.

[deebloo]

could be an object? First option will throw error if no files found. Current syntax would work as it does now

{
  "files": [
    {  "path": "src/**", "required": true  }, 
    "./some-generated-file.yml"
  ]
}

[appsforartists]

Good defaults are important.

I'd be open to using a literal to mark something as potentially missing, but string literals should be assumed to be real files. Optimize for the common case, not the outlier.

[deebloo]

makes sense. I was. thinking of situations where the output of one job is used as the input for another. I also was thinking about the error being a lint error not a runtime error (which re-reading the issue isn't correct). If that is the case swapping it around makes more sense

{
  "files": [
    "src/**", 
    { "path": "./some-generated-file.yml", "optional": true }
  ]
}