Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 0 additions & 3 deletions .eslintrc.json

This file was deleted.

32 changes: 32 additions & 0 deletions eslint.config.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
/*
Copyright 2020 Adobe. All rights reserved.
This file is licensed to you under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License. You may obtain a copy
of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under
the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS
OF ANY KIND, either express or implied. See the License for the specific language
governing permissions and limitations under the License.
*/

const aioLibConfig = require('@adobe/eslint-config-aio-lib-config')

module.exports = [
...aioLibConfig,
{
files: ['test/**/*.js'],
languageOptions: {
globals: {
jest: 'readonly',
describe: 'readonly',
test: 'readonly',
expect: 'readonly',
beforeEach: 'readonly',
afterEach: 'readonly',
beforeAll: 'readonly',
afterAll: 'readonly'
}
}
}
]
21 changes: 8 additions & 13 deletions package.json
Original file line number Diff line number Diff line change
Expand Up @@ -10,23 +10,18 @@
"jsonwebtoken": "^9.0.0"
},
"peerDependencies": {
"@adobe/aio-lib-ims": "^7"
"@adobe/aio-lib-ims": "^8.1.2"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@itavy One thing I want to double check here is the peer dependency move from @adobe/aio-lib-ims@^7 to ^8.1.2. I understand we needed 8.1.2 for the audit cleanup , but it means consumers using aio-lib-ims-jwt with aio-lib-ims@7 will now get peer dependency issues, right?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dthampy Great catch! You're absolutely right - this is a breaking change. Let me break down the implications:

Analysis

The concern is valid - changing from ^7 to ^8.1.2 has compatibility implications.

Impact:

  1. Consumers on aio-lib-ims@7.x will get peer dependency warnings
  2. This should be a major version bump (5.0.2 β†’ 6.0.0), not a patch
  3. We're enforcing a minimum version to ensure the uuid vulnerability is resolved

Options Considered:

Option A: Keep ^8 instead of ^8.1.2

  • Less restrictive (allows 8.0.0+)
  • Audit warnings persist for consumers on 8.0.x-8.1.1, but it's a false positive (nested copy not used at runtime)

Option B: Keep ^8.1.2 and release as v6.0.0 ⭐ RECOMMENDED

  • Forces consumers to use the fixed version
  • Released as major version (6.0.0) to properly signal breaking change
  • Cleaner from security perspective - no audit warnings
  • Once aio-lib-ims updates to depend on v6.0.0, the circular dependency resolves correctly

Option C: Revert to ^7

  • Most conservative
  • Keeps compatibility but maintains audit warnings

Key Insight:

We already introduced a breaking change in commit 1 by moving from ^7 to ^8. The question is just how restrictive to be within v8.

Since:

  1. We're already breaking compatibility with v7
  2. We should enforce the fixed version (8.1.2+) to eliminate audit warnings
  3. Major version bump properly signals this to consumers

I recommend Option B - keep ^8.1.2 and release this as v6.0.0.

Question:

Is aio-lib-ims@7 still actively maintained, or is everything moving to v8 now? This would help determine if we need to maintain backwards compatibility or if a clean break is acceptable.

What do you think?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update: Long-term Option D

After analyzing the codebase, I found that the circular dependency can be broken by extracting shared code!

Option D: Extract @adobe/aio-lib-ims-core ⭐ BEST LONG-TERM

Why the circular dependency exists:

  • aio-lib-ims imports aio-lib-ims-jwt as a plugin
  • aio-lib-ims-jwt only needs 2 methods: ims.getApiUrl() and ims.exchangeJwtToken()

Solution: Create new core package with just those methods:

aio-lib-ims-core (NEW)
β”œβ”€β”€ Core IMS functionality (API URLs, token exchange)
└── Plugin interface definitions

aio-lib-ims-jwt
β”œβ”€β”€ depends on: aio-lib-ims-core (NOT aio-lib-ims)
└── implements: ImsPlugin interface

aio-lib-ims
β”œβ”€β”€ depends on: aio-lib-ims-core
└── depends on: aio-lib-ims-jwt (as plugin)

Benefits:

  • βœ… No circular dependency (clean architecture)
  • βœ… No audit false positives
  • βœ… Easier to add more auth plugins
  • βœ… Proper separation of concerns

Effort: ~1-2 weeks for extraction, refactoring, and testing

Implementation: Can be done as pre-releases (beta) to validate before stable

I've created a detailed proposal: Issue #79


Recommendation

Short-term (this PR): Go with Option B - keep ^8.1.2, release as v6.0.0
Long-term: Consider Option D (core extraction) as outlined in #79

The short-term fix gets us moving now, while the long-term fix provides the cleanest architecture.

Thoughts?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Additional Context: JWT is Deprecated

Important discovery: JWT authentication is officially deprecated as of June 30, 2025.

From Adobe Developer docs:

As of June 30, 2025, Service Account (JWT) credentials have reached their end of life and are no longer supported. All server-to-server integrations must use the OAuth Server-to-Server credentials.

Impact on Our Discussion

This changes the context for both short-term and long-term decisions:

For this PR (Option B):

  • Still valid - existing JWT consumers need updates
  • But consider: How long should we maintain JWT support?

For Option D (core extraction):

  • Lower priority if JWT is sunset soon
  • Higher priority if OAuth uses similar plugin architecture
  • Questions: Does @adobe/aio-lib-ims-oauth use the same patterns? Would core extraction benefit OAuth implementation?

Key Questions for @dthampy:

  1. What's the support timeline for JWT (immediate sunset vs. gradual deprecation)?
  2. Is aio-lib-ims-oauth the recommended path forward?
  3. Does OAuth benefit from the same architectural improvements?

Migration Guide: https://developer.adobe.com/developer-console/docs/guides/authentication/ServerToServerAuthentication/migration

This context should inform our decision on whether to invest in architectural refactoring vs. minimal maintenance mode.

},
"devDependencies": {
"@adobe/eslint-config-aio-lib-config": "^4.0.0",
"eslint": "^8.57.1",
"eslint-config-standard": "^17.1.0",
"eslint-plugin-import": "^2.31.0",
"eslint-plugin-jest": "^27.9.0",
"@adobe/eslint-config-aio-lib-config": "^5.0.0",
"eslint": "^9.0.0",
"eslint-plugin-jsdoc": "^48.11.0",
"eslint-plugin-n": "^15.7.0",
"eslint-plugin-node": "^11.1.0",
"eslint-plugin-promise": "^6.6.0",
"globby": "^14.0.2",
"jest": "^29",
"jest-junit": "^16.0.0",
"globby": "^16.0.0",
"jest": "^30",
"jest-junit": "^17.0.0",
"neostandard": "^0",
"stdout-stderr": "^0.1.9",
"typescript": "^5.1.6"
"typescript": "^6.0.0"
},
"engines": {
"node": ">=20"
Expand Down
Loading