I’ve noticed that lately Modulus and Heroku deploy times take a very very long time. Deploying a small hello world app in Heroku is taking 8 minutes and it uploads a ~130mb This is also using v1.2.1
-----> Fetching Meteor 1.2.1
Using cached Meteor 1.2.1
-----> Unpacking Meteor 1.2.1
Meteor 1.2.1 is installed
-----> Building Meteor App Bundle
It sticks around the ‘Building meteor app bundle’ point ^^
Running meteor build .. takes 25.5 seconds to produce the tarball and it’s only 7.8mb locally. I do know that MUP is way faster than both Heroku and Modulus so maybe the latter has to compile Meteor and install Node each time?
I found it most noticeable when trying to use Heroku’s new pipeline feature which lets you spin up an app for a new PR and deploys upon merging to master.
I wish I knew more about the buildpacks but here is the full log if anyone has more info:
-----> Fetching set buildpack https://github.com/jordansissel/heroku-buildpack-meteor.git... done
-----> meteor app detected
-----> Moving app source into a subdirectory
Node engine: 0.10.40
Npm engine: unspecified
Start mechanism: none
node_modules source: none
node_modules cached: false
NPM_CONFIG_PRODUCTION=true
NODE_MODULES_CACHE=true
PRO TIP: Use 'npm init' and 'npm install --save' to define dependencies
See https://devcenter.heroku.com/articles/nodejs-support
PRO TIP: Include a Procfile, package.json start script, or server.js file to start your app
See https://devcenter.heroku.com/articles/nodejs-support#runtime-behavior
-----> Installing binaries
Downloading and installing node 0.10.40...
-----> Building dependencies
Skipping dependencies (no source for node_modules)
-----> Checking startup method
-----> Finalizing build
Creating runtime environment
Exporting binary paths
Cleaning up build artifacts
Build successful!
/tmp/build_c845ec1aa853985cef67869c25618f0c/foo-app-3a138486283528327bc28892b7d0c2f32825e2ca
└── (empty)
-----> Fetching Meteor 1.2.1
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
-----> Unpacking Meteor 1.2.1
Meteor 1.2.1 is installed
-----> Building Meteor App Bundle
-----> Installing App's NPM Dependencies
npm WARN package.json meteor-dev-bundle@0.0.0 No description
npm WARN package.json meteor-dev-bundle@0.0.0 No repository field.
npm WARN package.json meteor-dev-bundle@0.0.0 No README data
> fibers@1.0.5 install /tmp/build_c845ec1aa853985cef67869c25618f0c/AdamBrodzinski-erb-dashboard-3a138486283528327bc28892b7d0c2f32825e2ca/build/bundle/programs/server/node_modules/fibers
> node ./build.js
`linux-x64-v8-3.14` exists; testing
Binary is fine; exiting
ansi-regex@0.2.1 node_modules/ansi-regex
ansi-styles@1.1.0 node_modules/ansi-styles
escape-string-regexp@1.0.3 node_modules/escape-string-regexp
chalk@0.5.1 node_modules/chalk
has-ansi@0.1.0 node_modules/has-ansi
strip-ansi@0.3.0 node_modules/strip-ansi
supports-color@0.2.0 node_modules/supports-color
eachline@2.3.3 node_modules/eachline
type-of@2.0.1 node_modules/type-of
amdefine@1.0.0 node_modules/amdefine
asap@2.0.3 node_modules/asap
underscore@1.5.2 node_modules/underscore
meteor-promise@0.5.0 node_modules/meteor-promise
promise@7.0.4 node_modules/promise
source-map-support@0.3.2 node_modules/source-map-support
semver@4.1.0 node_modules/semver
source-map@0.1.32 node_modules/source-map
fibers@1.0.5 node_modules/fibers
-----> Discovering process types
Procfile declares types -> (none)
Default types for buildpack -> web
-----> Compressing...
Done: 163.1M
-----> Launching...
Released v4
https://foo-pr-2.herokuapp.com/ deployed to Heroku
What I noticed taking a lot of time is downloading the npm dependencies defined in packages. This is done one by one and consumes most of the build time in my experience. This is another reason why the npm integration is great in 1.3. A “normal” npm install is way faster and it also gives the ability to cache the NPM packages to reuse on a later build, as is done in the normal node buildpack:
So with some meteor buildpack improvements and with the new meteor 1.3 the build time could improve greatly. This does not solve your 1.2 problem of course, but I thought I would mention it anyway.