feat: support osls v4 (migrate provider.request to AWS SDK v3)

[jbsilva]

Problem

Under osls v4, the bundled AWS SDK v2 surface was removed, so provider.request() now throws:

provider.request() is no longer available. Construct AWS SDK v3 clients with
configuration from provider.getAwsSdkV3Config() instead.
(AWS_SDK_V2_SURFACE_REMOVED)

Because getEndpointInfo() calls provider.request('CloudFormation', 'describeStacks', ...) on every deploy, any service that uses this plugin fails to deploy on osls v4. The invoke command hits the same wall via four more provider.request() calls.

Change

• Add a small awsRequest() helper (lib/awsRequest.js). When the provider exposes getAwsSdkV3Config() (osls v4), it builds the matching AWS SDK v3 client (@aws-sdk/client-cloudformation, @aws-sdk/client-sfn) and sends the command. Otherwise it falls back to the legacy provider.request() (serverless v3), so existing behavior is unchanged.
• Route all five call sites through it: deploy/events/apiGateway/endpointInfo.js and the four in invoke/invoke.js.
• The request params and response fields already match between the v2 and v3 APIs used here (describeStacks → Stacks[].Outputs, startExecution → executionArn, describeExecution → status, getExecutionHistory → events), so call sites stay otherwise untouched.
• Declare osls (>=4) as an optional peer dependency.

Backward compatibility

On serverless v3 (where getAwsSdkV3Config is absent) the helper delegates to provider.request() with the exact same arguments, so there is no behavior change. The existing unit tests, which stub provider.request, continue to pass unchanged.

Tests

• npm test: 616 passing (613 existing + 3 new).
• New lib/awsRequest.test.js covers the SDK v3 path (via a stubbed CloudFormationClient.prototype.send), the legacy provider.request fallback, and rejection on an unsupported service/method.
• eslint clean on all changed files.

Verified end to end by deploying a real service (API Gateway + Step Functions) on osls v4.

Note on package-lock.json

I intentionally did not regenerate package-lock.json. The current tree has a pre-existing dev-dependency peer conflict (eslint@^10 vs eslint-config-airbnb-extended@3.0.1) that forces --legacy-peer-deps and rewrites the entire lock, which would bury this change in noise. Please regenerate the lockfile in your environment to pick up the two new runtime deps (@aws-sdk/client-cloudformation, @aws-sdk/client-sfn).

[bartelemi]

This is really neat 💪🏻

Would really like to see this included in the next release of the plugin. This is the last piece that is stopping us from migration to OSLS v4.

[jbsilva]

This is really neat 💪🏻

Would really like to see this included in the next release of the plugin. This is the last piece that is stopping us from migration to OSLS v4.

Thanks!

I actually published my fork to npm yesterday: https://www.npmjs.com/package/@jbsilva/serverless-step-functions

But having this upstream would be great.

[zirkelc]

Thanks for the PR, looks good!

@VirtueMe what do you think?

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/serverless-operations/serverless-step-functions@789

commit: f765cef

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.43%. Comparing base (f1a9ca6) to head (f765cef).
⚠️ Report is 406 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff             @@
##           master     #789       +/-   ##
===========================================
+ Coverage        0   99.43%   +99.43%     
===========================================
  Files           0       65       +65     
  Lines           0     6033     +6033     
===========================================
+ Hits            0     5999     +5999     
- Misses          0       34       +34     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.