You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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).
The text was updated successfully, but these errors were encountered: