My problem isn't refreshing in Dev mode. It's making sure when we do a push to our internal production environment or our public one, users are forced to get the latest code. Right now we just did a big change and push to internal production. We are starting up in production mode.
And users who have visited the site before are seeing the site broken until they clear their cache.
I've had a lot of experience and url based cache busting is by far the most effective in guaranteeing users see synced up to date static files.
Ok, got it now. So, essentially, the solution with the current mojito is to use mojito-shaker. Mojito itself should not be serving static files, normally, static files are build and pushed to CDN. Shaker can do that for you, but if you don't have a CDN, or your product should run off from your own network, Shaker can do that too, by hashing the files based on the content of each file, as well as creating rollups.
That being said, mojito next (probably 0.7.x) will have some new features built-in to build and version yui modules and other assets.
I tried using shaker and just found the documentation and implementation extremely lacking. I also didn't see where it was adding url based cache busting. I understand it's well integrated into your systems but it just didn't seems to be doing anything when I was using it. I used the shaker frame and added a definition into my application.json and ran shaker. But when I then ran mojito it didn't appear to have even comboed the urls. It also just seemed like Shaker was a little out of sync with Mojito as far as docs and functionality.
Is there any way to get something like what I proposed in #2 of my last post into mojito soon? I have no idea how long 0.7 will be and need a solution relatively quickly.
@Jesse, I can assure you that shaker does DO what you want, and @albert is very responsive, if you have any question or issue, you can open an issue in github under yahoo/mojito-shaker repo, cc' me if you want.
One of the big problems of the current mojito is that it does too much magic for users, so advance users like you will have a hard time changing things, and bending features. This is something we truly want to fix in 0.7.x. I wrote the combo and all the other pieces related to the loader, and I can probably help, but I should warn you that all those stuff are pretty complex and you have cero hooks to modify them from outside, so you will have to replace many pieces to bend it.
@Jesse, we are focused on mojito-next (0.7) at the moment, I don't think we will get back and add those hooks for you. You can copy that particular script in the yui_modules folder (at the app level), and you should be able to modify them and they will overrule any file coming from mojito (yes, app has precedence here).
That will unblock you for the time been. Just keep in mind that you have to keep an eye on any patch release for 0.6.x so you might need to recopy and rebuild the custom scripts.
Just as a follow up, I did get Shaker working. But I was partially right about it's short comings. I had a real hell of a time getting it working until I realized, it is out of sync with Mojito and does not work with 0.6.
Also the default config used in the examples won't cause Shaker to do anything with your assets. You have to specify a location other than 'default' for any of your assets to get minified, etagged, or even comboed. This is really unclear in the documents. It might be a good idea for the 'default' to be local. Or change your example to use local. It would have saved me a lot of time.
@Jesse, thanks for the note, but I guess that will be more useful as a issue under mojito-shaker repo. As for the compatibility with 0.6, I am sure there is a version that goes well with it because the team behind a big project at Yahoo! is the team behind shaker and they are running 0.6 as today :), just make sure you ask for details thru the proper channels.