SLS_AWS_SDK_V3 - Add ability for plugins to extend COMMAND_MAP and CLIENT_MAP

[andrew-ignatiev]

Hey guys, it's so great that you released serverless core code to use AWS SDK V3. Thank you for all your efforts. I am pretty sure that after the end of support for AWS SDK V2 on September 8, 2025, many more developers will want to migrate their serverless infrastructure to use your fork.

I have tested it with our real live projects, and unfortunately found that migration to your fork will not be straight forward with SLS_AWS_SDK_V3=1 due to incompatibility issues with serverless plugins which we use. For example our Node.js serverless projects use next plugins:

• serverless-deployment-bucket
• serverless-stack-termination-protection
• serverless-associate-waf
• serverless-prune-plugin

and each of them will throw error mainly due to non existed method in COMMAND_MAP or non existed client for service in CLIENT_MAP. I've found workaround on my side, in short I implemented local serverless plugin which apply monkey path to your provider and extend support of more services and methods. It's not ideal, but gives some further thoughts how it can be improved.

I clearly understand that you are not going to rework hundreds of existing plugins or extend oss-serverless core functionality to support them. But it could be done by community if they will have public API in provider to extend those hardcoded maps.

Solution proposal

I suggest you will add 2 new public methods in AWS provider https://github.com/oss-serverless/serverless/blob/main/lib/plugins/aws/provider.js

registerCommandClassV3(serviceNameV2, methodNameV2, commandClassV3);
registerClientClassV3(serviceNameV2, clientClassV3);

So anyone who will want to fix work of their used plugins will check what services and methods plugin request. Then create local or published serverless plugin to patch work of broken plugin.

Example for serverless-prune-plugin. Let's create oss-serverless-prune-plugin-patch with next code:

'use strict';

// Lambda Commands
const {
  DeleteLayerVersionCommand,
  DeleteFunctionCommand,
  ListAliasesCommand,
  ListLayerVersionsCommand,
} = require('@aws-sdk/client-lambda');

const { LambdaClient } = require('@aws-sdk/client-lambda');

class OssServerlessPrunePluginPatch {
  /**
   * @param serverless
   * @param options
   */
  constructor(serverless, options) {
    this.patched = false;
    this.options = options;
    this.serverless = serverless;

    this.hooks = {
      'after:deploy:deploy': this.patch.bind(this),
      'before:deploy:deploy': this.patch.bind(this),
      'before:package:initialize': this.patch.bind(this),
      'before:aws:common:validate:validate': this.patch.bind(this),
    };
  }

  patch() {
    if (this.patched) {
      return;
    }

    const provider = this.serverless.getProvider('aws');
    if (!provider) {
      this.serverless.cli.log('AWS provider not found');
      return;
    }

    provider
      .registerCommandClassV3('Lambda', 'deleteLayerVersion', DeleteLayerVersionCommand)
      .registerCommandClassV3('Lambda', 'deleteFunction', DeleteFunctionCommand)
      .registerCommandClassV3('Lambda', 'listAliases', ListAliasesCommand)
      .registerCommandClassV3('Lambda', 'listLayerVersions', ListLayerVersionsCommand);

    provider.registerClientClassV3('Lambda', LambdaClient); // just an example

    this.patched = true;
  }
}

module.exports = OssServerlessPrunePluginPatch;

So in serverless.yml we will be able to patch serverless-prune-plugin

service: my-test-service
useDotenv: true

# You can pin your service to only deploy with a specific Serverless version
# Check out our docs for more details
frameworkVersion: ^3.24.1

# Setting the variable resolution mode to a version that will interpret
# StringList ssm parameters as a list of strings
variablesResolutionMode: 20210326

plugins:
  - oss-serverless-prune-plugin-patch
  - serverless-prune-plugin

...

[andrew-ignatiev]

@GrahamCampbell Do you have any thoughts on it?

[mnapoli]

That makes sense, but I think we'd need some plugin maintainers to actually be interested in using that before we spend any effort supporting this.

[GrahamCampbell]

Another approach could be that we well plugin maintainers to use their own client instances, instead of using ours.

[mnapoli]

That would be a good idea indeed. More effort on their part though, but it makes sense.

[andrew-ignatiev]

My main concern was about using existing serverless plugins as is without changes and with minimum effort to patch them for correct work with oss-serverless _requestV3. Adding those 2 public methods in the provider will give us the possibility to easily patch broken plugins with core functionality of oss-serverless (aws-sdk v3) but without editing plugins themself.

I mean most of the plugins use code provider.request(service, method, params, options) and there is no good way to make them work without a public API in the provider to extend your client and command maps.

Btw, the approach with plugin-patch from the example works perfectly. But obviously this required me to rework the _requestV3 behavior (monkey patch), which is not a stable solution.

[GrahamCampbell]

If they just used their own clients, and just get the auth from us, then there should be no issues.

[GrahamCampbell]

I think plugins using our provider stuff was a bad idea from the start.

[andrew-ignatiev]

It would be a big problem of using oss-serveless with aws-sdk v3 without ability to re use existing serverless plugins. So you need to have clear statement for community that oss-serverless wouldn't work with existing plugins when you stop rely on aws-sdk v2 and such issues will not be resolved #40

I'm not sure why do you think it's bad idea to use oss-serverless provider and give ability to extend your command and client maps without dependencies in oss-serverless. Could you please explain?

Your core logic perfectly works with plugins when maps contain necessary Command and Client classes.