fix: improve build file naming convention and caching

[doraemonxxx]

Reference issue: https://github.com/vbenjs/vue-vben-admin/issues/3905 In revision: https://github.com/vbenjs/vue-vben-admin/commit/a6086f4cc8f33fea7431f3d39eb73dda20c325bd

(EDITED) Using entryFileNames: 'index.js' in Vite is generally not recommended due to several issues:

1. Debugging Difficulty: Identical filenames make debugging harder as they don't reflect their origin or purpose.

Advantages of using [name]-[hash]

1. Clarity: Each output file retains a clear connection to its entry file, making it easier to identify what each file corresponds to.
2. Consistency: This naming convention is more consistent if you have many files, as each file keeps its original name with a hash appended, making the build output more organized and predictable.

Also in Dockerfile it uses entry directory

CMD sed -i "s|__vg_base_url|$VG_BASE_URL|g" /usr/share/nginx/html/dist/assets/entry/index-*.js

https://github.com/vbenjs/vue-vben-admin/blob/8d3981f599f073b226c822a8d28af9aecf00a667/Dockerfile#L23C2-L23C99

General

✏️ Mark the necessary items without changing the structure of the PR template.

• [x] Pull request template structure not broken

Type

ℹ️ What types of changes does your code introduce?

👉 Put an x in the boxes that apply

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

Checklist

ℹ️ Check all checkboxes - this will indicate that you have done everything in accordance with the rules in CONTRIBUTING.

👉 Put an x in the boxes that apply.

• [x] My code follows the style guidelines of this project
• [x] Is the code format correct
• [x] Is the git submission information standard?
• [x] My code follows the style guidelines of this project
• [ ] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] My changes generate no new warnings
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] New and existing unit tests pass locally with my changes
• [ ] Any dependent changes have been merged and published in downstream modules

[wangjue666]

cc @xachary