Based upon student experience, here are some suggestions for better managing your Meteor experience.
When starting a Meteor project within IntelliJ, you will frequently get an error like this in ESLint:
The problem is that this package is located in your project node_modules directory, not the global node_modules directory, so you need to tell IntelliJ to look in the local node_modules directory for ESLint. Bring up the Preferences page for ESLint and correct the path to look in the local project’s node_modules directory like this:
After correcting the path and clicking OK, this error message should go away.
When you invoke meteor npm run start
to run your application for the very first time, you can expect to sometimes wait up to a minute regardless of your platform or machine specifications. The long time for initial build of a Meteor application is frustrating, but as of Meteor 1.6, it is “normal”.
On the other hand, once Meteor has built the application (i.e. the console prints out the message that you can retrieve the application at localhost:3000), then the “refresh” process upon changes to your code should happen quickly, say within 10 seconds. If refresh is slow, then there is an issue with your environment to investigate.
The Meteor Development Group has indicated that improving initial build time is a priority for an upcoming release.
So, don’t worry about startup times of around a minute. Do worry if startup times take several minutes, or if refresh times are also slow. This either indicates a problem with your configuration (i.e. a virus checker is running) or in the worst case, a problem with your hardware.
If you switch branches while Meteor is running, you are essentially changing the database and application files out from under the running Meteor process, which will generally lead to strange application behavior.
The safest approach to switch branches during Meteor development is to:
One reason Meteor can be unpredictably slow is because, by default, it checks for updates and downloads them automatically as part of the build process. To disable this behavior, you can pass --no-release-check
to the meteor command.
In this class, you should always bring up your Meteor application using:
$ meteor npm run start
The start script, among other things, adds the --no-release-check
flag.
You may see a warning similar to this when starting up Meteor:
Note: you are using a pure-JavaScript implementation of bcrypt.
While this implementation will work correctly, it is known to be
approximately three times slower than the native implementation.
In order to use the native implementation instead, run
meteor npm install --save bcrypt
in the root directory of your application.
bcrypt is a password-hashing algorithm used during authentication. Since logins are a low frequency event for your applications in this class, there is no real performance impact of a pure-Javascript implementation. In addition, on Windows, attempting to install the native implementation of bcrypt can be time-consuming and error-prone.
So, don’t worry about this warning.
If you find that IntelliJ is taking more than a minute to index your application when you first create a project, then try “invalidating caches and restarting” using the File > Invalidate caches/Restart menu.
Users have reported that this solves the problem of indices taking many minutes to build.
Alternatively, you can “pause” indexing by clicking on the pause icon on the bottom pane of the IntelliJ window.
The package.json files for the template Meteor applications in this class run ESLint with the “quiet” flag, which suppresses warnings:
"scripts": {
"lint": "eslint --quiet ./imports"
},
So that you get the same behavior inside IntelliJ, you need to pass –quiet as an “extra eslint option”. Set this up in the ESLint configuration panel:
As mentioned in the laptop requirements page from the first week of class, you should have an adequately configured laptop running the latest version of Windows 10. If you have ignored these requirements, then none of the following tips might help you.
Some Windows users report very slow startup times for Meteor or IntelliJ can be solved by disabling virus scanners.
To determine if this is a problem, use Windows Task Manager to see if another process is using most of the CPU resources while IntelliJ or Meteor is starting up. For example, here is a screen shot of Windows Task Manager when Meteor (i.e. Node.js) is starting up:
As you can see, “antimalware service executable” is using most of the CPU resources. A quick google shows that this program is part of Windows Defender, and the link disabling Windows Real-Time Protection shows how to disable it temporarily.
On Windows, it is unwise to disable Windows Defender permanently as this leaves your computer vulnerable to malware. According to Google, each “temporary disable” of Windows Defender lasts a couple of days.
According to this post, you should try editing the Windows Defender exclusions list to ignore around six directories. If you are using another AntiVirus software, you can try excluding these programs are excluded from them as well.
For those of you having long installation or extraction times for Meteor on Windows, you can try to see if it’s an archiving issue by:
C:\Users\%username%\AppData\Local\.meteor\packages\meteor-tool\%version%\mt-os.windows.x86_32\dev_bundle\bin
Some students have reported compiler errors and other problems that were resolved by changing the association of javascript from Windows Script Host to IntelliJ IDEA.
To do this, go to Control Panel > Default Programs, and click on “Associate a file type or protocol with a program”. Then find .js, and change it to IntelliJ IDEA.
Windows 10 provides a native Linux environment called Ubuntu on Windows. If you are having problems getting Meteor to run on your Windows machine, consider running it in this environment. Note that you may want to install git and IntelliJ as well as Meteor so that you can do all development in this environment.