AWS SDK for JavaScript (v2)

repository·master·Indexed 27 days ago

https://github.com/aws/aws-sdk-js

The AWS SDK for JavaScript (v2) provides a collection of services to interact with AWS through JavaScript. This version is currently in end-of-support status as of September 8, 2025, and users are recommended to migrate to v3 using the aws-sdk-js-codemod package.

Tokens
2.8K
Snippets
14
Records
20
Agent score
93%

What's inside aws-sdk-js

  1. Migrate Base64 and Timestamp handling from 1.x to 2.x

    master

    In AWS SDK for JavaScript v2.x, the SDK automatically encodes and decodes Base64 and timestamp values. You no longer need to manually perform Base64 conversions for services like AWS.DynamoDB or AWS.SQS.

    • Input: Pass the raw string or Buffer instead of a Base64 encoded string.
    • Output: Base64 encoded values are returned as Buffer objects from server responses.
    // 1.x approach (Manual Base64)
    var params = {
      MessageBody: 'Some Message',
      MessageAttributes: {
        attrName: {
          DataType: 'Binary',
          BinaryValue: new Buffer('example text').toString('base64')
        }
      }
    };
    
    // 2.x approach (Automatic)
    var params = {
      MessageBody: 'Some Message',
      MessageAttributes: {
        attrName: {
          DataType: 'Binary',
          BinaryValue: 'example text'
        }
      }
    };
    
    // Reading the response in 2.x
    sqs.receiveMessage(params, function(err, data) {
      // buf is <Buffer 65 78 61 6d 70 6c 65 20 74 65 78 74>
      var buf = data.Messages[0].MessageAttributes.attrName.BinaryValue;
      console.log(buf.toString()); // "example text"
    });
  2. Migrate from AWS SDK for JavaScript v2 to v3

    master
    The AWS SDK for JavaScript v2 reached end-of-support on September 8, 2025, and no longer receives updates. It is highly recommended to migrate to AWS SDK for JavaScript v3. You can use the aws-sdk-js-codemod package to automate the migration of your application from v2 to v3.
  3. Document JavaScript code with yard-js

    master

    Documenting with yard-js is similar to YARD for Ruby. You add docstrings directly above method or class definitions. Unlike JSDoc, you do not need to explicitly denote the class name or details, as yard-js automatically detects them using conventional syntaxes. All YARD macros and tags are supported.

    /**
     * This class represents files on disk.
     *
     * @see FileSystem
     */
    inherit(IO, {
      /**
       * Opens a new file at the location of `filename`
       *
       * @param filename [String] the location on disk of the file to open.
       * @param access [String] a combination or 'r' and 'w' for access modes.
       */
      constructor: function (filename, access) { ... },
    
      /**
       * Reads from the open file
       *
       * @param numBytes [number] the number of bytes to read. Leave this
       *   empty to read all remaining data.
       * @return [Buffer] the data read from disk as a buffer.
       */
      read: function (numBytes) { ... }
    });
  4. Specify version bumps for the release script

    master

    When running the release script, you can provide an argument to specify how the version should be bumped. If no argument is provided, the script defaults to a patch bump.

    Accepted Arguments:

    • major: Bumps the major version.
    • minor: Bumps the minor version.
    • patch: Bumps the patch version.
    • A specific version number (e.g., 2.4.6) that must be greater than the current latest version.

    Example: If the latest version is 2.4.5, running ./scripts/changelog/release minor will set the new version to 2.5.0.

    ./scripts/changelog/release minor
  5. Generate documentation with yard-js

    master

    To generate documentation for your project, navigate to your project directory and run the yard command via bundle exec, specifying the yard-js extension path. Use -m markdown to use markdown formatting for documentation comments instead of the default RDoc format.

    $ bundle exec yard -m markdown -e /path/to/yard-js/lib/yard-js.rb
  6. Access Request ID via response.requestId in 2.x

    master

    When upgrading from 1.x to 2.x, the location of the Request ID has changed to improve consistency across services. The property response.data.RequestId has been renamed to response.requestId.

    If you are accessing the ID inside a callback, use this.requestId.

    // 1.x (Old)
    svc.operation(params, function (err, data) {
      console.log('Request ID:', data.RequestId);
    });
    
    // 2.x (New)
    svc.operation(params, function () {
      console.log('Request ID:', this.requestId);
    });
  7. Add a change entry using add-change cli

    master

    Use the add-change script to create a new changelog entry via an interactive prompt. The script will prompt you to specify:

    • type (e.g., bugfix or feature)
    • category (e.g., a service name like S3 or a component like Paginator)
    • description (a short summary of the change)

    This script creates a JSON file in $SDK_ROOT/.changes/next-release/. You must include this generated JSON file when submitting a pull request.

    Requirements:

    • Requires a Node.js version that supports promises (0.12.x or higher).
    node ./scripts/changelog/add-change.js
  8. Recreate the changelog using create-changelog

    master

    If the changelog is deleted or corrupted, you can recreate it using the create-changelog script. This script generates the changelog based on JSON files located in the .changes/ directory at the SDK root.

    Requirements:

    • A .changes/ directory must exist in the root.
    • JSON files must be named with a version number (e.g., 2.4.5.json).
    • Each JSON file must contain an array of objects. Each object must have the following string properties:
      • type
      • category
      • description

    Note: Incorrectly formatted filenames are skipped, but incorrectly formatted JSON in correctly named files will cause the script to error and halt.

    ./scripts/changelog/create-changelog
  9. Remove .Client and .client property usage in 2.x

    master
    The .Client and .client properties have been removed from Service objects in v2.x. If your code references these properties on a Service class or an instance, you must remove them and call operations directly on the service instance.