In reviewing the source for the project here I noticed that it's making a global configuration update instead of providing these options to the DocumentClient constructor which is supported as noted here and here. It would seem it would be best to transition these to use the constructor instead of the global config.
This raises a further question though. What if a user had the need to configure additional properties for the DocumentClient that this library chose not to expose?
I see a few potential ways to proceed:
- Keep the public API of the package the same and transition to use the constructor for a more narrow configuration update but this prevents any other options from being configured.
- Add to the public API essentially exposing all configuration options for
DocumentClient.
- Expose the ability to provide an instance of the
DocumentClient in a non-breaking change.
- Expose the ability to provide an instance of the
DocumentClient in a breaking change.
I'm more than happy to submit a pull request to make any adjustments but I wanted to understand if this is a change that would be considered and what the preferred option would be.
Thanks!
In reviewing the source for the project here I noticed that it's making a global configuration update instead of providing these options to the
DocumentClientconstructor which is supported as noted here and here. It would seem it would be best to transition these to use the constructor instead of the global config.This raises a further question though. What if a user had the need to configure additional properties for the
DocumentClientthat this library chose not to expose?I see a few potential ways to proceed:
DocumentClient.DocumentClientin a non-breaking change.DocumentClientin a breaking change.I'm more than happy to submit a pull request to make any adjustments but I wanted to understand if this is a change that would be considered and what the preferred option would be.
Thanks!