Web SDK v5.0.0 Migration Guide

Installation

Following the recent changes with Amity Social Cloud, the Web SDK is now published under a different name.

To install the new v5 version, you will have to run the following commands:

npm uninstall eko-sdk # uninstall version 4
npm install --save @amityco/js-sdk # install version 5

After that, you'll have to change your imports accordingly. You can easily do this by performing a global "search and replace" and put eko-sdk as input and @amityco/js-sdk as output. You should end up with a diff looking like this:

-import Client from 'eko-sdk'
+import Client from '@amityco/js-sdk'

After that, we also renamed the sets of constants for consistency.

Handling Breaking Changes

Don't worry, we didn't change much! Only errors and constants were impacted since we used to prefix them. Aside from this, we did not introduce any change in SDK's logic.

If you are looking for a quick win which will fit 90% of the projects, we recommend you to perform a quick "search and replace" and erase the "Eko" prefix from your code wherever you used it. That is that simple!

For the most precautious, here's an exhaustive list of the names we changed.

Eko Client (optional)

The main object you'll interact with is our SDK Client. This class can be freely renamed since it is the default export of our package (ie: import EkoClient from "eko-sdk") so there should be no problem keeping it like this if you prefer.

In the eventuality that you'd like to keep the name we gave in the source code, please find that we rename the class to ASCClient.

Errors (optional)

Globally found, there will be no need to adapt your code except if you specifically added try catch blocks for those error classes.

Constants (mandatory)

All these can be found as named exports at the root of our package (ie: import { EkoFileType } from "eko-sdk"). You will have to manually change those.

Client

LiveObject

User

File

Reactions

Channel

Message

Community

Post

Comment

Conflicting Names

In case you're already using any of those names in your own codebase, you can easily manage by renaming the named imports with the as keyword.

import { CommentDataType } from './my-own-module'

// use "as" to rename as you see fit and avoid conflicts.
import {
  CommentDataType as ASCCommentDataType,
} from '@amityco/js-sdk'