mceachen
commented
4 months ago I had it set up this way in the past, and this caused confusion from people that didn’t rtfm. Also, due to how exiftool behaviors change without regard to semver, I can only support the currently vendored version.
If there’s a way to encode this conditionally, I’d be open to that, but what you’re suggesting will break literally all current users of this library (unless I’m misunderstanding your request).
Describe the bug Exiftool-vendored depends on opening "exiftool" as a childprocess. -> the exiftool-executables needs to be present for it to work.
In our deployment process it's harder to include npm dependencies without pure js content. So we do not include one of the possible optional dependencies, but include the exiftool (with the correct version) ourselves and create the Exiftool-Wrapper with a custom exiftool-path. Problem: At the moment one of the optional Exiftool-Dependencies are required (even if it is not used), because the DefaulExiftoolOptions does require one of the dependencies.
To Reproduce Do not install one of the optional dependencies. -> Just importing the files results in an error ("Cannot find module ...")
Expected behavior The lib should be usable without optional dependencies, but with specified exiftool-path.
Problem in Code: DefaultExifToolOptions (in src/DefaultExifToolOptions.ts) is a const. -> the default-value for "exiftoolPath" is directly computed -> the default-value computation for "exiftoolPath" calls "findExiftool()" in src/FindExiftool.ts -> here the optional dependencies are required
--> this default value is not used if the user specifies an own exiftool-installation