Iâm surprised it hasnât been mentioned yet. I would love to have an âofficial docker imageâ;
FROM mdg/meteor:1.8
RUN meteor build .
Another thing I thought of a couple of days ago, is this feature request
Basically; I think that it would be quite possible to have a meteor.bundle.js
and a app.bundle.js
now that Meteor has dynamic imports. This meteor.bundle.js
doesnât need to be recompiled on every app change. Not even on every app update.
Benefith 1, the user can have a more aggresive cache
Benefith 2, meteor builder can treat this meteor.bundle.js
as a single, static file. And have way faster build times. (package recompiling / scanning still takes a lot of time here)
I know you can manage the client-cache benefith yourself already, by using an import()
as early as possible. But, I think this can be stretched, by hosting the meteor.bundle.js
on a CDN, allowing all meteor apps
to share some cache.
<body>
<script src="https://cdn.meteor.com/meteor-1.8.min.js" />
<script src="/e58e...3d8.js" />
</body>
Yes, that does mean that you would possibly have some packages loaded that you donât use. ButâŚ, if looking on the bigger picture. The more sites use Meteor, the bigger the chance that your visitor already has this bundle in itâs cache any way.
Stretching the idea bove, using precompiled bundles that are slightly âover completeâ, could perhaps be used to build the official meteor docker images.
Imagine building FROM
a base container with the meteor assets
already precompiled, and only need to compile my own additions and node_modules.
My top layer could be under 10mb, where as the base layer is a simple download from docker hub.