Next Feature Release
What's coming in the next release
You can chose to use either reference implementation as is, or you can expand upon them to tailor them exactly to your project's requirements.
If you would prefer to use a library other than Browserify and Rollup then you can provide your own scripted implementation for the library of your choice.
What's changing in the next release
Before Trio was even a project, the ability to cache bust a website generated by it was acknowledged as a major required feature that must be provided in the future project's toolchain. So the development of a cache-busting facility was begun which ultimately resulted in the delivery of Buster.
At the time of Buster's initial development it was decided that Buster was to serve two roles, one as a standalone utility and one as member of Trio's toolchain. As a standalone utility Buster would have to be dynamic enough to satisfy a variety of use cases that its users may require. However, as part of Trio's toolchain Buster would be used only to cache bust "in place", meaning that cache busting is applied directly to the files in the release folder and no ability to restore or reverse the actions of cache busting would be needed because that could be satisfied by merely rebuilding the project for release.
Since its initial release, Buster has become quite popular as a standalone utility and over time a pattern of its use as a standalone utility has emerged - the vast majority of its users are using Buster to cache bust their own projects "in place", just as how Trio internally uses Buster to cache bust its projects "in place".
With that revelation has come a decision to refactor Buster with the objective of simplifying its code base by removing all features that are not directly involved with cache busting "in place". The result will be a smaller and simpler code base that will be easier to maintain and which will be more in line with how it is actually being used by a vast majority of its users.
As an added benefit of refactoring an annoying bug in Buster will finally be addressed, and that is Buster's propensity to apply a file hash twice to a URL when it points to a file whose own name is in part used by another URL. For example, when hashing mybundle.js and mybundle.js.map Buster would ultimately hash mybundle.js.map as hash-hash-mybundle.js.map. This bug has long been a pain point and addressing it in this refactoring will be a very high priority.
If you are currently using Buster as a standalone utility and you aren't using it to cache bust "in place" then we sincerely apologize for any inconvenience these changes may bring you. However, it shouldn't be very difficult to refactor your own projects to use Buster's cache busting "in place" by simply directing your project's build process to generate its release files into a dedicated folder which then can be targeted by Buster to be cache busted "in place".