I just ran the Meteor visualizer on a Meteor 1.6 RC3 project and I noticed there is a dynamic-versions.js file that 123KB in size. I don’t recall seeing this file in the earlier versions but maybe I’m wrong.
Any comments on the purpose and size of this file?
If you take a look at that file:
It says it includes a tree of hashes of all dynamic modules. Can you take a look in the built version what the file contains?
Thanks @coagmano, I’m using dynamic import at a react router level and I’ve relatively large app so that it could explain the file size.
Forgive my ignorance, but where exactly do you think I can find this file?
Thank you.
Okay I tried the visualiser on a project using dynamic imports on 1.6.rc-6 and when I ran it with
meteor -s settings.json --production --extra-packages bundle-visualizer
I found the dynamic-versions.js file here:
.meteor/local/build/programs/server/packages/dynamic-import.js
Interestingly, mine had an empty object where __DYNAMIC_VERSIONS__ was, so 
Yeah, not sure either, but the generated file size is a big concerning…
Did you manage to find the file in your build? What’s taking up so much space in it?
I still can’t find the generated file at the client.
But my guess that it’s keeping some sort of hash that identifies the packages which are being dynamically imported and since I’ve a mid-size app that’s getting divided at the routes, there is a lot to hash.
Do you think I should open an issue on this to bring it to Benjamn’s attention?
Yeah, It really shouldn’t be that big. So it’s a good call
Did you manage to make dynamic-versions.js smaller? any comment from Benjamin?
checked my closed issues it doesn’t seem I’ve opened one.
But somehow the load time is good, it’s than 1.2s so I guess I let it go. It’s been while so I don’t recall what I changed exactly, I suspected I added then SSR and got happy with the initial render but I’ll keep an eye next time I run the bundle visualizer to see if that number change.
However it’s worth pointing that while SSR improves the initial paint time, the bundle size has big impact on the interactive time so both need to be optimized.
Can you share from your experience doing SSR with react and meteor.
Do you have recommended resources?
Well when I did the SSR implementation as soon as the server-render meteor API was released and I only did for the two main routes the login and the home page because those are the pages that got hit first so I was trying to improve the first paint time.
The issue I faced back then was how to get the user data and I’ve followed the solution from the fast render library by using cookies to figure out the user and simply render the react component for the given route.
The great pub framework also has SSR but they’re using Apollo you can find it here, which is kind similar to what ended up with.
Here is a snippet of a code block I’ve in the SSR I hope it helps a bit.
if (user && path === '/') {
log.info('SSRing home url..');
sink.appendToBody('<div id="react-root"></div>');
const route = getMatchedRoute(App.getActivePackage(), path);
if (route && route.ssr) {
log.info(`ssr is requested for route ${path}`);
sink.renderIntoElementById(
'react-root',
renderToString(
stylesheet.collectStyles(
<AppLayout>
<NewsFeedLoader user={user} posts={SSRData} />
</AppLayout>
)
)
);