Maintenance: deprecate customConfigService and ConfigServiceInterface

[svozza]

Summary

When we replaced EnvironmentVariablesService with the functional env helpers (#4146, #4168, #4188, #4225, #4251, #4314) we removed the implementation but never marked the public seam it sat behind. customConfigService and ConfigServiceInterface are still present and still honoured, with no @deprecated tag, so nothing tells users the option is on its way out.

Why is this needed?

The config service will be removed in a future release and users shouldn't be relying on it. It appears nowhere in docs/ or examples/, so the @deprecated tag in the API reference is the only signal a user will ever get.

Which area does this relate to?

Commons, Logger, Metrics, Tracer, Idempotency

Solution

Markers only, no behaviour change:

• @deprecated on ConfigServiceInterface in commons/src/types/ConfigServiceInterface.ts and the logger, metrics and tracer variants.
• @deprecated on the customConfigService option in logger/src/types/Logger.ts:102, metrics/src/types/Metrics.ts:46 and tracer/src/types/Tracer.ts:29, pointing users at constructor options and the POWERTOOLS_* environment variables instead.
• Delete packages/idempotency/src/types/ConfigServiceInterface.ts, unreferenced since refactor: idempotency env service to functions 4246 #4314.

Acknowledgment

• This request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[dreamorosi]

Sure, let’s mark the public seam it sits behind 🤣

Jokes aside, yes good catch - let’s mark it as deprecated.