Migrating from v1 to v2

Even though the changes between v1.x and v2.0 are significant, V2.0 attempts to keep the migration process simple.

Breaking Changes to the API

1. Instantiate Evaporate with the new create class method and not with the new keyword. The default AWS Signature Version is now 4. If you are using AWS V2 Signatures, then you must explicitly specify the signature when creating an Evaporate instance: awsSignatureVersion: '2'.
2. The .add() method now returns a Promise. Assure that your code uses the Evaporate instance passed when the Evaporate.create resolves.
3. If your application uses .pause(), .resume() or .cancel() then you need to make sure to pass the correct file key to these methods. V1.6.x used the return value from .add() as the key to the upload to pause, resume or cancel. In v2.0 it returns a Promise that resolves when the upload successfully completes. To identify the file upload in these methods, you need to construct a file key according to the documentation of these methods.
4. If you use awsLambda signing, you need to use the new pluggable signing method feature (customAuthMethod) because built-in support for AWS lambda has been removed. Follow the instructions here.
5. signResponseHandler now only acts on the response from signUrl. It cannot be used to sign a request on its own. To sign a request without using signUrl, use a pluggable signing method specified with customAuthMethod.
6. If you require support for browseers that do not implement ES6 Promises (Internet Explorer), you will need to include a compliant Promise polyfill such as es6-promise.

Changes to Basic Retry on Error Behavior

1. With the addition of pluggable signing methods implementing the Promise interface, it is possible for the signing method promise to reject. Previously, Evaporated treated virtually any error in the upload process as a trigger to (indefinitely) retry the request. As of v2.0, if the pluggable signing method rejects, the file upload will also reject. If you use the functionality provided through signerUrl, then the upload will reject if the signing request responds with HTTP Status 401 or 403.