steal
steal copied to clipboard
Production build number
@justinbmeyer has expressed interest in Steal providing a build number of some sort that can be used by libraries. This issue is to discuss this issue and how it can be implemented.
One constraint is that this feature shouldn't block browser caching, so appending a number into the bundles won't work.
@matthewp Can you remind me why that wouldn't work again?
Note that I'm talking about the idea to put a build number into the generated steal.production.js
. This wouldn't work because it would cause steal.production.js to not come from the cache.
what is about this idea:
- untouch the
steal.prduction.js
- on build create a
bundles.json
file that contain all the bundles that today will write into the bundled file
/*[system-bundles-config]*/
System.bundles = {"bundles/access-index":["[email protected]#util"]};
put this file on the dist folder right next to the steal.production.js
- on production env lets do this script tag
<script src="dist/steal.production.js" main="my-app/main" bundles="bundles.json"></script>
or put thissteal.bundles = "bundles.json";
on thesteal.production.js
file because it would never chang
steal will load this bundle file first. then load the my-app/main
file.
to cache-bust the changed file, put a hash on each bundles js-files, that hash changes if the content of a bundle change.
a build number can be generated by steal by serialze the bundles.json
file and create a hash of that string (in real-time). maybe steal.buildNumber()
What if the build number was written into the main? Yeah, you'd have to load the main even if there weren't any other changes in it, but I don't think that matters practically so much.
- https://github.com/canjs/can-connect/issues/56 is somewhat related
The main bundle is usually the largest bundle, it's the one that you want cached the most.
@justinbmeyer is there a bug in can-connect that describes the need for this type of functionality? I'd like to understand the use-case better.
@matthewp I guess my point would be that on a new release, you've almost certainly changed the main bundle. That having it change with the build number would overlap so often that the times it didn't might be ok forcing everyone to get a new version.
It's definitely possible to change only 1 page of your application which would then result in only that bundle changing. I don't know what percentage of the time that is, but I wouldn't want my main bundle to skip the cache in that case.
@matthewp i want to work on this feature like i described in my comment. can you confirm that this is a way it could / should work?
No, I don't think so because it would mean you'd have to wait for this bundle config to load before loading the main bundle. Which would cause the app to load slower.
I'd really like to learn more about the use-case before we proceed with a sub-optimal solution. I don't want to do anything that causes slower production loads unless there is a very strong reason for it.