Using KeyPrefix does not delete the s3 bucket after "sls remove" command.

[thescientist23]

This is a:

• [] Feature request or change
• Bug report

---

For bug reports:

Expected behavior

"sls remove" should remove the bucket

Actual behavior

objects was deleted but the bucket remains, although it is empty but in a long run it will pile up on my aws account.

Steps to reproduce

Added KeyPrefix to yml file.

custom:
   client:
     keyPrefix: 'samplepref'

Below is the result of "remove" command.

I think this block of code has something to do with the behavior.

• **Operating system:osx
• **serverless-finch version:2.8.0
• serverless.yml that produces bug:
• Command that produces bug:
• Other details:

---

For feature requests or changes:

Current behavior (if any)

Proposed behavior

Proposed implementation deatils (optional)

Justification

[mikejpeters]

On one hand I think it makes sense not to remove the bucket when keyPrefix is being used, since ait could be used used when deploying to a bucket that also contains other data. But there may be other use cases, such as making the deployment match the naming conventions of frontend frameworks / tools.

@thescientist23 if you're still interested in this functionality can you please explain why you're using keyPrefix but also want the bucket removed?

I think if we want to support removing the bucket when keyPrefix is in use it should be using a new option.

[fernando-mc]

@mikejpeters seconding what you're saying here. This could have unintended consequences that I'm not comfortable with. If we add support for this it should be in a new feature/setting.

[thescientist23]

@mikejpeters , thanks for your response, I am using KeyPrefix for my custom domain, basically for developing feature branch, eg. https://domain.com/feat-1, https://domain.com/feat-2,...etc. and to map the location according to feature branch I am deploying the react app on non root path thats where the KeyPrefix came into play.

[mikejpeters]

Thanks for the response. I'm assuming you wouldn't want this plugin to delete the bucket if there are still other objects i (e.g. in your case feature branches)?

@fernando-mc can you weigh in on this again when you have a chance? If the plugin deletes the objects at the prefix, and then only deletes the bucket if it's completely empty I don't see a downside. But maybe I'm missing some danger / use case? Having a new option like "force remove bucket" is safer but IMO less user-friendly. I like having smart defaults / less options, even if it means releasing a new major version with breaking changes

[fernando-mc]

@mikejpeters - I also prefer clean sensible defaults so as long as we release this with a major version bump I'm fine with it. I agree it probably makes sense and there's aren't many people who would object to it but it does change default behavior destructively and there's always some weird use cases we can't predict.

When including this:

1. Add a warning to release notes
2. Bump a major version

Then we're covering our bases and should be fine.

[github-actions]

🎉 This issue has been resolved in version 4.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀