Allow boolean values in bower.json file created by bower init
#1819
Conversation
|
👍 |
|
However I think it is worth noting that it looks like with the new implementation of |
|
Yeah, I wanted to make the most narrow fix I could. Since the bower.json spec documents the expected types (Object, Array, String, Boolean), we should not have to worry about numbers. |
|
I've added a comment to the new method referencing the allowed types and the documentation. |
|
👍 |
|
@sheerun looks like you've been doing a lot of integration work on bower—is there anything I should do to get this merged? |
|
I think we should include numbers for forward compatibility |
A change in the behavior of `mout.lang.isEmpty()` in Mout v0.10.0 introduced a bug in `bower init`, preventing it from including Boolean values in "bower.json". This commit explicitly whitelists the types that are used in the bower.json spec - Object, Array, String, Boolean - as well as Number for future compatibility.
|
Seems reasonable, thanks @sheerun. Pushed a new commit - I've also changed the logic to explicitly whitelist valid values, so this is easier to read and reason about. |
|
Looks good! Thanks! |
Allow boolean values in bower.json file created by `bower init`
|
Thank you |
Hi!
While using
bower initthis morning, I noticed that the resulting bower.json file did not include the "private" key I had chosen a value for. It looks like the behavior ofmout.lang.isEmpty()was changed in mout v0.10.0 (discussion), and Bower's dependency on mout introduced this bug, preventingbower initfrom being able to create a complete bower.json.Interestingly, this buggy(?) behavior is captured in the bower test for init, where the input includes "private", but it is not in the expected output, so forgive me if this behavior is in fact intended :).
Also, I almost never write JavaScript, so please let me know if there are style/other issues to fix.
Thanks for looking!
<3 Ben