"No success message": success regex isn't reliable indicator of "success" about exiftool-vendored.js

[mceachen]

Thanks for bringing this issue up!

I think it would be better to rely on exit code from exiftool

For performance reasons, I run exiftool in "batch" mode, so there's no exit code to check.

The errors (like file not found) are easy to handle, as ExifTool will emit to stderr--I think it's defensible to throw an error if exiftool renders to stderr.

but if exiftool actually failed (missing binary, input file doesn't exist, etc)...I want to know and parsing error messages from your lib feels like a brittle way to do this.

Totally agreed. So--I could

1. throw a custom error with some field you could check to see why it failed, or
2. only throw if ExifTool emits to stderr, and update ExifTool.write to return a Promise<something> that indicates the operation was a no-op.

I think I prefer 2. It's a breaking change, but I think it's better than what I've got currently.

So: what's something look like?

1. {state: "created" | "updated" | "unchanged"}
2. {noop: boolean}
3. {created?: number; updated?: number; unchanged?: number}
4. something else (suggestions welcome)

Option 1. allows for discrimination for creates vs updates, but checking a boolean might be a bit simpler than messing with a string enum.

Option 3 requires consumers to query a bunch of fields, but supports writes to filenames with globs, like:

exiftool -Author= foo*.xmp
    1 image files updated
    6 image files unchanged

[mceachen]

OK, I'm implementing Option 3:

export interface WriteTaskResult {
  created: number
  updated: number
  unchanged: number
  warnings?: string[]
}

[mattpr]

Hey! Thanks for the fast response and turnaround on a patch. I appreciate it!