[FIXED] Generate .meteor/local packages, Flow type checking

We are using Flow type checking with Meteor, and currently we have the following in our .flowconfig:

# Meteor none core package support
# e.g. "meteor/kadira:flow-router"
module.name_mapper='^meteor\/\(.*\):\(.*\)$' -> '<PROJECT_ROOT>/frog/.meteor/local/build/programs/server/packages/\1_\2'

# Meteor core package support
# e.g. "meteor/meteor"
module.name_mapper='^meteor\/\(.*\)$' -> '<PROJECT_ROOT>/frog/.meteor/local/build/programs/server/packages/\1'

# Fallback for Meteor core client package
# e.g. "meteor/meteor"
module.name_mapper='^meteor\/\(.*\)$' -> '<PROJECT_ROOT>/frog/.meteor/local/build/programs/web.browser/packages/\1'

This works fine when doing local development, however it fails on our CI server, because the local directory is only populated once meteor run has run at least once…

Is there a way to populate this directory with a command that we could put in our CI setup-script (which just does all the installation etc, and then immediately quits)? Or another way to support Flow type checking?


Maybe try meteor --get-ready? I seem to remember that doing something like this but I’m not sure if it’s only for Meteor development or works with apps as well.

Thanks a lot for your response, I didn’t know about --get-ready. However, removing .meteor/local, and running it, I get a .meteor/local directory with isopacks and plugin_cache, but not a build directory, which is what the .flowconfig is looking for. I also tried build and build --debug, but that did not add to the .meteor/local directory either.

So the way we ended up fixing it is in this pull request. Basically, I added a check in server/main.js to see if a certain environmental variable has been set, if it has, the server immediately dies. I run meteor with --once, to avoid restart, and I run meteor in this way once in my CircleCI script, before the flow type checking, which means that everything works.

1 Like

This is not the first time someone has run into the need to build without running. The solution you came up with is actually exactly what I’ve offered as a work-around before in this issue.

I think the only outstanding question on that PR would be the exact name of the flag, but we can figure that out later. If you’d be willing to make a contribution to Meteor, we’d be willing to review it – and I’ve marked that PR appropriately. Please discuss as appropriate on the issue!