Added info to README about how to clean up old files after deploying

[euan-forrester]

I wrote a companion plugin that helps to cleanup the S3 bucket after deploying by tagging all files in the deployment directory in S3 that are not on the local machine. Thus, any files with old hashes will be tagged and can be expired in a set number of days using S3 lifecycle rules.

This helps prevent the bucket from becoming filled with old files, making it difficult to tell which is the most current version of a given file.

I added a link to this new plugin to the README -- please let me know your thoughts!

[multiplegeorges]

Awesome, great idea for a plugin. Thanks for the contribution!

[euan-forrester]

Awesome, thank you very much!

[Roriz]

if we use more of aws cli, this problem never has been exist, on aws-cli sync has a flag to delete any remaining file https://docs.aws.amazon.com/cli/latest/reference/s3/sync.html

[euan-forrester]

This is definitely interesting but unfortunately it doesn’t solve this use case: the client browser can have some, but not all, of your files cached and if the cached file(s) contain references to now-deleted files then the client browser will throw a 404. So we need to keep the old files around for a while until everyone’s cache clears.

On Friday, August 28, 2020, Radamés Roriz notifications@github.com wrote:

if we use more of aws cli, this problem never has been exist, on aws-cli sync has a flag to delete any remaining file https://docs.aws.amazon.com/ cli/latest/reference/s3/sync.html

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/multiplegeorges/vue-cli-plugin-s3-deploy/pull/118#issuecomment-682871850, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI3JWTBUZHKGZLZYKTLOZOLSC7NTZANCNFSM4OABBEUA .

[Roriz]

This is definitely interesting but unfortunately it doesn’t solve this use case: the client browser can have some, but not all, of your files cached and if the cached file(s) contain references to now-deleted files then the client browser will throw a 404. So we need to keep the old files around for a while until everyone’s cache clears. … On Friday, August 28, 2020, Radamés Roriz @.***> wrote: if we use more of aws cli, this problem never has been exist, on aws-cli sync has a flag to delete any remaining file https://docs.aws.amazon.com/ cli/latest/reference/s3/sync.html — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI3JWTBUZHKGZLZYKTLOZOLSC7NTZANCNFSM4OABBEUA .

If you use CloudFront can resolve this problem of cached files. Cloudfront creates a copy and distributes this file cross the all global if any use request this file persistent, this file with continue cached until anyone request more for X hours (CloudFront don't make explicit these rules of cached). We are on the browser if using maintain cache about the old version is always bad in my opinion.

[euan-forrester]

You're welcome to set up your pipeline as you wish, but I wouldn't advocate for requiring CloudFront in everyone's pipeline in order to address this issue. And I don't think it's a best practice to use a cache to be able to serve old versions of the files if the browser requests them: you may wish to invalidate your CloudFront distribution for other reasons, like pushing out a critical bug fix, and if that causes some users to see a 404 then you will have someone very upset with you :)

And, to be clear, we aren't using the browser to do anything: all we can do is to request that they don't cache one of our files, but they can still choose to, and it can still lead to a 404.