An issue I am having is that the options loaded in this way bypass validation, so bogus parameters can be inserted, and (more importantly for my case), type validation is not attempted. For example, if a Thor option is changed from a string to an array, if the config file sets that option as a string, it will remain as a string in the options hash. If code is dependent on this option being an array, things begin to fall apart.
If there's a way to instead merge a hash with the hash from https://github.com/rails/thor/blob/e4907fdd663d0a1ff51d18eb1827552ee61300a3/lib/thor/parser/options.rb#L88-L139, that would probably work (i.e. override that method and merge one hash over the other). One issue with this (and the original method) is that defaults are resolved without us knowing if option values are default or user-provided. If there's a way to provide the initial hash before defaults are resolved, that would be ideal.
Hello,
I am currently setting options from a file, similar to what is described in https://github.com/rails/thor/issues/413.
An issue I am having is that the options loaded in this way bypass validation, so bogus parameters can be inserted, and (more importantly for my case), type validation is not attempted. For example, if a Thor option is changed from a string to an array, if the config file sets that option as a string, it will remain as a string in the options hash. If code is dependent on this option being an array, things begin to fall apart.
If there's a way to instead merge a hash with the hash from https://github.com/rails/thor/blob/e4907fdd663d0a1ff51d18eb1827552ee61300a3/lib/thor/parser/options.rb#L88-L139, that would probably work (i.e. override that method and merge one hash over the other). One issue with this (and the original method) is that defaults are resolved without us knowing if option values are default or user-provided. If there's a way to provide the initial hash before defaults are resolved, that would be ideal.
Thank you!