Remove dependency on AWS-SDK
We're only using the AWS-SDK to create a DynamoDBSet. Let's try and emulate it and drop the dependency
Now that the aws-sdk has moved to the peerDependencies, is there a need to write our own implementation of DynamoDB.Set? The goal has always been to make this lib dependency free, but it doesn't make sense to use it without a aws-sdk present. It's not very wise to have our own DynamoDB.Set, either. I think we can close this?
One gotcha is that this lib will currently only work with AWS SDK v2. It's not compatible with v3 because of different imports needed. There are four options, I think:
- Maintain two separate branches/versions of this package that target aws-sdk v2 and v3 separately. In that case, semver would be abandoned.
- Maintain two separate npm published packages that mostly share code but differ in terms of set creation for v2 and v3.
- Require the caller to pass in an optional
DocumentClientreference that would only be required if the input contains a set. With that, the library would be able to defer to the caller. - Have set creation work off Dynamic imports using
requirestatements wrapped intry/catchblocks. Try importing v3, and if it's not available, import v2.
I would love to see a v3 compatible version of this library. We personally use it quite heavily and are trying to remove deps on v2 aws-sdk versions.
ok, let me look into this. I favor option 3 on @bilalq post, what you guys think?
Yeah option 3 sounds good to me.
I just pushed v3 which no longer depends on AWS SDK. If (and only if) you need to work with Sets, you provide it as a parameter like this:
import { DocumentClient } from "aws-sdk/clients/dynamodb";
const params = dynoexpr({
DocumentClient,
Update: {
Color: new Set(['Orange', 'Purple'])
},
})
Let me know if it works for you. All types are prefixed with I now, which makes it not backward compatible, but the code calls stay the same. If you're working with Sets and you don't provide the SDK it will throw an error.