[obarcelonap]

Description

Widens the @adobe/aio-lib-ims peer dependency range from ^7 to ^7 || ^8, matching the range @adobe/aio-lib-ims-oauth already declares.

Related Issue

N/A — no existing issue tracked this; opening directly since it's a minimal, low-risk peer-range fix backed by a public advisory (linked below). Happy to file one first if preferred.

Motivation and Context

Because the current peer range only accepts aio-lib-ims v7, npm cannot resolve this plugin against an already-installed aio-lib-ims v8 and instead nests a legacy aio-lib-ims v7 copy alongside it. That legacy copy depends on aio-lib-state@3.x, which depends on @azure/cosmos@3.x, which depends on uuid@8.3.2 — vulnerable to GHSA-w5hq-g745-h8pq ("Missing buffer bounds check in v3/v5/v6 when buf is provided", CVSS 7.5).

Widening the peer range lets consumers already on aio-lib-ims v8 resolve this plugin against that version directly, avoiding the nested legacy chain and the vulnerable uuid version entirely.

How Has This Been Tested?

Ran the existing test suite (npm test, lint + unit tests) — all pass with 100% coverage.

To confirm this widening isn't breaking, I compared the actual interface contract between aio-lib-ims v7.0.2 and v8.1.2 (installed side by side as a transitive/nested pair, so a direct diff was possible):

• Plugin-loading code (src/token-helper.js) is byte-for-byte identical between v7.0.2 and v8.1.2 — same require('@adobe/aio-lib-ims-jwt'), same canSupport / supports / imsLogin(ims, config) calling convention this plugin relies on.
• This plugin never imports @adobe/aio-lib-ims itself — it only receives an ims instance as a parameter and calls two methods on it: ims.getApiUrl(api) (in createJwt) and ims.exchangeJwtToken(clientId, clientSecret, signedJwtToken) (in imsLogin). Both methods have identical signatures and behavior in src/ims.js across v7.0.2 and v8.1.2.
• Diffing ims.js in full between the two versions shows the only changes are unrelated to this plugin's usage: JWT payload decoding switched to base64url-safe padding, HTTP error messages now include the response body, and a minor reordering of token validation logic. None of it touches getApiUrl or exchangeJwtToken.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[yeshwanthkai]

@obarcelonap To be clear, This PR is aimed to fix the uuid vulnerability coming from aio-lib-ims v7 only, right? I see that the same vulnerable uuid package is being used by jest-junit and I assume that falls outside the scope of this PR. Am I correct?

[obarcelonap]

@yeshwanthkai yes that's correct