I’ve had several conversations online and off with people using Windows, and the consensus is that the (vocal) Meteor-on-Windows community is small, and everyone has their own particular environment. Many common issues arise, though, so I want to share some of my experiences should anyone else in Windowsland come across them. It’s a little haphazard, and there might be better ways of doing things, but here it is. Please comment with any tips or advice.
Meteor Development on Windows 7
I use Windows 7 at my job. I’ve never used Windows 8 or 10, so I don’t know how well they will work, but they should. The official Windows installer from Meteor has worked just fine for me.
MongoDB
The only thing I change about the default Meteor setup is installing a persistent version of MongoDB (as a Windows service) so I can browse, dump, and restore data when Meteor is not running. To do this yourself, create an environment variable called MONGO_URL and set it to the URL of your running mongo instance.
I’m currently running Mongo 3.0.8 locally, and have not yet tried 3.2.
JetBrains
For my IDE, I use JetBrains products (WebStorm and IntelliJ IDEA). The Meteor support is top-notch. Project setup is a breeze, code highlighting is great, clicking on template items will bring you to your helper functions, etc… The main benefit, though, is the debugger. You can live-debug, trace, and place breakpoints on both client and server code – all in one handy interface. Webstorm is super cheap, and 100% worth it.
Building a Meteor App on Windows 7 (64-bit)
Running
is where the pain begins. There are a few things that need to be done before successfully extracting a working bundle from Meteor in Windows.
An when I refer to meteor build, or bundle, I am referring to the output of the command:
meteor build --directory c:\mymeteorapp
More Environment Vars
You need to set ROOT_URL to http://localhost (or whatever you want) and PORT to a valid port number if you want something other than 3000. I use port 3030 so the bundled app doesn’t conflict with the development version running on port 3000.
If you are using Meteor settings, the entire json block needs to be stringified and pasted into the METEOR_SETTINGS environment variable.
The following Powershell 3.0 snippet will do this for you (assuming you run these commands from a directory with a file named settings.json):
$settings = Get-Content settings.json -Raw
$settings = $settings -replace "`n","" -replace "`r","" -replace " ",""
[Environment]::SetEnvironmentVariable("METEOR_SETTINGS", $settings, "Machine")
Please note, I am no Powershell expert (or even a novice). Use at your own risk.
Build Dependencies
Visual Studio. In order to build the fibers module (and possibly other node extensions), you’ll need some build tools. I currently have Visual Studio 2013 AND 2015 (free Express/Community editions) installed locally. I’m pretty sure you only need 2015, but remember to check the c++ build tools options when installing. You don’t actually have to open Visual Studio, just have it installed.
Python. Also, Python 2.7 is a requirement. So install Python 2.7.
Node.js. You probably have NodeJS installed, but Meteor expects 0.10 (32-bit). I’m using 0.12 (64-bit), which has gone OK so far aside from the problems listed below. I have no idea about 4.2, or 5+. If you want to keep your precious bleeding-edge versions of Node, I highly recommend using this: https://github.com/coreybutler/nvm-windows.
Situational Build Dependencies
NPM3. If you have any Meteor packages that include a very deeply nested set of node_modules dependencies, then you are going to run into the 256 character limit for file directory paths in Windows (still a thing after all these years!). Go ahead and install npm3 (and make sure it’s install directory is included in your PATH), and we’ll use it later. To install npm3, use npm!
or check the GitHub wiki.
64-bit bcrypt. If you are using meteor-accounts, then the bcrypt module is required. Because the Meteor dev environment uses a 32-bit version of node, a 32-bit bcrypt module is included with the build. To get a 64-bit version of bcrypt, you need to install Win64OpenSSL. Then go to an empty directory and install bcrypt with npm like:
npm install bcrypt --openssl-root="C:\some\other\path\to\openssl"
then dig around in the node_modules folder until you find bcrypt_lib.node. Hang on to it for later. This GitHub issue has some nice background info.
Meteor Build
Take a deep breath and run
meteor build --directory "C:\yourbuilddir"
This will do a bunch of things, and hopefully spit out a node application in C:\yourbuilddir. You’re not out of the woods yet. Go into
and run
. More things will happen. Hopefully without error (and only a handful of warnings).
If you are using bcrypt, enter the build directory and find: bundle\programs\server\npm\npm-bcrypt\node_modules\bcrypt\build\Release\ and overwrite the bcrypt_lib.node file there with the one you installed earlier.
To run the app, go into the \bundle directory and run
from CMD. If you don’t get any ugly errors, try navigating to http://localhost:3000 (or whatever is specified in your env vars) and see if your app works.
Fixing the 256 character file-path limitation
Your Meteor app should run in place, even if you have some insanely long file paths. However, copying, deleting, and pushing to a remote repo will cause problems. The basic fix for this is to go into the offending package, delete the node_modules folder, and rebuild it with NPM3 so it uses a flat folder structure. There are two ways (that I’ve found) to fix this problem…
If you are developing alone on a single PC, you can simply go to your global packages directory (e.g. C:\Users\\AppData\Local.meteor\packages) and find the offending package with a long dependency chain. Remove the node_modules folder, and run npm install to rebuild it with a flattened dependency tree.
This becomes problematic when updating modules or developing with a team. Everyone will have to remember to do this every time the module is updated. An alternative is to rebuild node_modules folders after meteor build has run. Then it can be an automated part of your build script.
After running meteor build, go into c:\\bundle\programs\server\npm\\node_modules\\ and delete the node_modules folder. Then run npm install from the same folder. NPM3 should take over and install a flattened dependency tree.
Running the build
Go into C:\\bundle\ and run
You should see a blinking cursor. This is good. Open a browser and go to http://localhost:3030 (or whatever you specified in your environment vars) and hopefully see your app running.
Coming soon… Deploying this to Windows Server 2012 behind IIS.
