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.
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: