I've reviewed a ton of packages that fulfill the same general purpose and am leaning towards this one. We use ssm-diff (with a bunch of PR'd improvements) to populate/administer parameter store using YAML files so nesting is natural for us. I really like how this package exposes those nested keys to the app. I also find the general approach sound.
The one thing that's attractive in other packages and not found in this one is the option to use multiple paths (e.g. separated by ; or :). This option makes it easier to import both server-specific configurations and common configurations (e.g. database). In other packages that support multiple paths, it's understood that keys in later paths may overwrite keys in earlier paths (both a practical requirement and a feature).
I see the advantages of path-as-environment-variable, but it also means that you can't workaround the one-path limitation by, for example, wrapping the app with two calls to the package (each with different paths).
I've reviewed a ton of packages that fulfill the same general purpose and am leaning towards this one. We use
ssm-diff(with a bunch of PR'd improvements) to populate/administer parameter store using YAML files so nesting is natural for us. I really like how this package exposes those nested keys to the app. I also find the general approach sound.The one thing that's attractive in other packages and not found in this one is the option to use multiple paths (e.g. separated by
;or:). This option makes it easier to import both server-specific configurations and common configurations (e.g. database). In other packages that support multiple paths, it's understood that keys in later paths may overwrite keys in earlier paths (both a practical requirement and a feature).I see the advantages of path-as-environment-variable, but it also means that you can't workaround the one-path limitation by, for example, wrapping the app with two calls to the package (each with different paths).