Closed silvio2402 closed 1 year ago
Thanks for this suggestion. I agree with you about how important good types are.
I'm getting the feeling that the actual type of RawTags is just anything json serializable
I think it should reflect what ExifTool actually renders. For the most part, that's just number | number[] | string
, but there are a handful of boolean tags, and struct
tags (like Face
, Look
, and CreatorContactInfo
) that support deeper structures (the -struct
argument is added by default for other readTags
calls). So... yeah. It's arbitrary JSON.
We can at least tighten up the top level RawTags definition a bit, as we know the top Record
is string-indexed.
/**
* Loosely typed raw result from ExifTool
*
* @see https://github.com/photostructure/exiftool-vendored.js/issues/138
*/
export type RawTags = Record<string, Json>
I'm releasing v21.4 with this update now.
Documentation/Type Issue Proper documentation and typing is very important. If for example a return value is wrongly typed, a developer might feel comfortable not checking the types at runtime which can cause issues.
The function at
ExifTool.readRaw
is noted to return field values of typestring | number | string[]
. However, the type of the return value is falsely defined asPromise<Tags>
in the builtExifTool.d.ts
file. I believe this is due to theReadRawTask
extendingExifToolTask<Tags>
.Could we create a type, for example:
...and use it to extend
ReadRawTask
withExifToolTask<RawTags>
, which would come at the cost of editor autocompletions of tags?But also the documentation for
ExifTool.readRaw
is wrong because I've seen it return boolean for some tags (for exampleFlashFired
). Also, how does readRaw handle structs?I'm getting the feeling that the actual type of
RawTags
is just anything json serializable, for which I would recommend this type:Please let me know if I've missed anything. I hope we can resolve this issue. Thanks for the work!