Currently, for ease of use, the CLI applies a set of heuristics to find a manifest file within the provided folder.
In the odd case that these heuristics incorrectly flag an error, or that a user has multiple packages in a single folder, it might be useful to allow some combination or arguments or options for specifying which file in the package is the manifest file, e.g.:
Approach 1: Positional argument can be directory or single file
ocf2ocx ./path/to/package would apply the existing heuristic as it does today
ocf2ocx ./path/to/package/manifest.json would skip the heuristic and load the specified file as the manifest
Approach 2: Additional option to specify which file is the manifest
ocf2ocx ./path/to/package would apply the existing heuristic as it does today
ocf2ocx ./path/to/package --manifest manifest.json would skip the heuristic and load the specified file, relative to the package, as the manifest
There are of course other options but I prefer Approach 1.
Currently, for ease of use, the CLI applies a set of heuristics to find a manifest file within the provided folder.
In the odd case that these heuristics incorrectly flag an error, or that a user has multiple packages in a single folder, it might be useful to allow some combination or arguments or options for specifying which file in the package is the manifest file, e.g.:
Approach 1: Positional argument can be directory or single file
ocf2ocx ./path/to/packagewould apply the existing heuristic as it does todayocf2ocx ./path/to/package/manifest.jsonwould skip the heuristic and load the specified file as the manifestApproach 2: Additional option to specify which file is the manifest
ocf2ocx ./path/to/packagewould apply the existing heuristic as it does todayocf2ocx ./path/to/package --manifest manifest.jsonwould skip the heuristic and load the specified file, relative to the package, as the manifestThere are of course other options but I prefer Approach 1.