path-style versioning of static asset
dberardo-com opened this issue Ā· comments
Is there an existing issue that is already proposing this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe it
no
Describe the solution you'd like
the idea is to have different versions for different JS files. There should be a default "latest" version for all clients not specifying a version, and versioning should be dealt with in a simple manner, like in a regular file system three. Also the number of folders and names should not be known in advance, and can be changed. example of folder structure:
- assets/js/
- some_js_asset/
- latest/ --> points to v3 (example symlink)
- 3.0/
- 2.9/
- 2.8/
- some_other_unversioned_js_asset/
- index.js --> (this would be the default "latest/") folder for this unversioned asset
- some_js_asset/
and then clients would be able to fetch:
localhost/assets/js/some_js_asset --> latest
localhost/assets/js/some_js_asset/latest --> latest
localhost/assets/js/some_js_asset/3.0/ --> v3.0
localhost/assets/js/some_js_asset?version=3 --> v3.0
localhost/assets/js/some_js_asset?minVersion=2&maxVersion=3 --> v3.0
localhost/assets/js/some_other_unversioned_js_asset/ --> latest
etc ....
Teachability, documentation, adoption, migration strategy
No response
What is the motivation / use case for changing the behavior?
the motivation is to have a server to serve microfrontend bundles for run-time mounting. see also: https://www.youtube.com/watch?v=QHunH3MFPZs&list=PLLUD8RtHvsAOhtHnyGx57EYXoaNsxGrTU&index=5
the rootPath directory will be mounted from a dynamic volume where CI pipelines would upload the compiled JS asset without having to restart the server
Thanks for your suggestion!
There are no plans to implement it in the foreseeable future.
If you think your request could live outside Nest's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.