Disable version checking during build? Or just do it once?

core
1

Hi, after I make changes in my code, Meteor automatically rebuilds my app, which is awesome.

But I’m waiting for alot of this:

   Checking for cosio55:autoform-cloudin...  |
   Checking for ddp@1.2.2                    /
   Checking for ddp-client@1.2.1             /
   Checking for sha@1.0.4                    \
   Checking for spacebars-compiler@1.0.7     |
   Checking for standard-minifiers@1.0.2     /

and because I’m using the micro-services pattern, it’s 5x and happening all at once.

For me, version checking needs to happen about once per week.

Is there a way to skip version checking during the build?

Or have it run in the background for the NEXT build (like downloading new meteor versions)?

Or have it just run the first build, but not subsequent ones (watched code changes)?

Gulp.js could do this. How do we do it in Meteor?

2 Likes
2

This is the result of not having a special meteor install command - so Meteor assumes that at any moment, your package dependencies, version requirements, or similar could change if you edit one of the files. Rails gets around this by having the bundle install command be run manually by the developer. I think that could be an improvement, or you could have a special way to start Meteor that skips the dependency checks.

3

Hmmm… It would seem like there are some specific places where those package dependencies and version requirements could be tracked.

What code in ‘client’, ‘lib’, or ‘server’ is going to change dependencies/versions?

Doing the full build on the first build of meteor run might be appropriate. But, for me, doing it every time after that is overkill. Especially if micro-services is a supported configuration. (It’s driving me nuts to see 8 processors go full-throttle in a 50 second build just because I saved a comment).

Based on other build frameworks (Rails, gulp.js, etc), I completely expect to have to restart the meteor run process when fiddling with dependencies/versions. And meteor add / meteor remove could signal the meteor run process anyways.

+1 for a --fastBuild that skips dependency checks altogether and/or a --firstBuild that does it just on the processes first build.

I looked at the code, but I’m unfamiliar with the build system (I know Gulp and Grunt). Would you accept a PR? Where to make the change?

4

As far as I know, meteor tracks packages from the .meteor/packages file, so unless that file gets changed, why should the packages should be re-checked? I could be wrong aswell ;o

5

One other thing may be turning off the stdout output of the individual packages to the console. This can slow a node process down considerably.

“The console functions are synchronous when the destination is a terminal or a file (to avoid lost messages in case of premature exit)”

https://nodejs.org/api/console.html#console_console_log_data

6

@michaelcole Hi, I have the same issue with Checking for. Building takes forever. How have you fixed it? Thanks in advance :slight_smile:

7

Hi Gris, MDG updated the build process in 1.3. I’m getting a much smoother build process now. Are you on 1.3?

8

Yes, I’m on 1.3.2.4. The strange thing is that after building a project with meteor command for some time everything works fine and builds fast, but after some time it starts to Check for when I have changes in the project. I can fix this by stopping meteor (Ctrl-C 2 times) and re-running (meteor command) again. But then after some time everything happens again.

9

@gris, if it’s reproducable, consider reporting it as a bug.

10

I also have this problem on my windows 10 laptop. first builds are faster than 2-hours-after builds

1 Like