Would you take a PR to throw an error for all empty configs?
See original GitHub issueCurrent behavior:
When using load(null, configPath)
cosmiconfig throws an error
When using load(dirPath)
cosmiconfig continues to traverse up the directory path
If this was intentional then please help me understand why. Otherwise I would like to create a PR to throw in all cases. I don’t really care whether an error is thrown, we’re mostly looking for a way to differentiate empty configurations from those which are non-existent. e.g. package.json
with an empty prettier
property should behave differently from a package.json without a prettier
property.
Edit: I was basing the above off of issue comments I was reading in the prettier repo - not off of local tests. When cosmiconfig sees a package.json file with "prettier": {}
, it correctly returns an empty object and does not traverse up the file tree. However it still treats an empty *rc file as non-existent. I now understand this is an edge case that really can really only help expose configuration errors made by developers.
Why
prettier-atom
would like to allow users to specify settings within the plugin for one-off cases where files do not belong to projects. However if any configuration is found, even empty then we would like to use that configuration instead. Empty signifying default settings.
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (4 by maintainers)
Top GitHub Comments
@olsonpm, When loading a specified file, the behavior was inconsistent if the file was empty(see https://github.com/davidtheclark/cosmiconfig/pull/78#issuecomment-318810892) and this was fixed in
v3.0.0
. However, when performing a search up the directory tree, I am not entirely sure that we should throw an error when we find an empty config file.If the pkg has an empty property, the search resolves with
{}
. The same is true for a JSON file with{}
as the contents. So would it be enough to check if the value thatcosmiconfig
search resolves to, is an empty object?resolve to empty cfg
package.json
:Empty configs are now handled consistently in the v5 branch, so closing this issue.