humanmade / humanmade/S3-Uploads

Consider "pruning" aws-sdk

Open
#736 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
PHP
Stars
2.2k
Forks
404
PR merge metrics
No merged PRs in 30d

Description

Hi! While auditing large vendor dependencies in our codebase, I noticed that aws/aws-sdk-php is being pulled in via this package. Given the size of the AWS SDK, this has a noticeable impact on the overall vendor footprint.

I was wondering whether you’ve considered pruning unused AWS services to reduce the installed size. The AWS PHP SDK actually provides native support for this via a Composer script that removes service clients that aren’t explicitly listed.

Reference:
https://github.com/aws/aws-sdk-php/blob/c45d13c95b188b6fc9f31c77083fad6e7dbc3efd/src/Script/Composer/README.md

Using this approach would allow consumers to keep only the services they actually use (e.g. S3), significantly reducing disk usage and deployment size, without changing runtime behavior.

Is this something you’d be open to optimize?

Contributor guide

No contributing guide indexed for this repository

Research direction

Read the AWS SDK Composer pruning README linked in the issue, then inspect this plugin’s Composer configuration and dependency usage. Determine which AWS services the package requires and define how pruning can preserve consumer-selected services while reducing the vendor footprint. Done means the dependency setup supports this optimization without changing runtime behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, php, wordpress
Domain
build-system, cloud
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.