My Meteor file change watcher is taking forever to detect my file changes and refresh the browser, sometimes even longer than a minute. This makes developing a real pain.
My Meteor is running inside an Ubuntu-VM. The projects folder lies in my OSX and is mounted inside the VM. So I'm aware that inotify/kqueue won't work, so Meteor should fallback to stat polling.
I even set the environment variables according to this post, but the behavior is still the same.
METEOR_WATCH_FORCE_POLLING=true
METEOR_WATCH_POLLING_INTERVAL_MS=500
Is there any way to fix this annoying behavior?
The folder from OSX is mounted as a nfs share btw.
Update:
I did some testing and there is no difference if the application has a big amount of packages or is taking long to build, even with the very basic app you get after meteor create I still get the same behavior.
If I change a file in the VM (so that inotify works) the refresh is happening instantly.
I've have apps in production that incrementally become slower when adding packages, both 3rd party and private packages. I also discovered that adding 3rd libs directly on the client/lib increases the reloading time.
I'm not sure if Meteor 1.0.2 actually solved the problem of watching the directory efficiently.
What version of Meteor are you using?
Much of this lag-reloading issue was addressed on Meteor 1.0.2. While it still takes some time, I would say was ~5x faster on my experience.
Related
I am new to Meteor. I just start using Meteor for the first time. It seems a bit slow. I am developing on a Macbook Pro with SSD. I am using Firefox, and Vim. I tend to save the files frequently, causing it to refresh the browser. It takes a few seconds for the browser to refresh. I do not have much code yet. Are you experiencing this slowness? How can this be improved? Does MDG have any plan to improve this? If I make change to a file, can we cause the browser to just reload that file rather than doing a full build and causing the browser to reload all the files? Am I missing something? Thank you!
Unfortunately, you can't do anything about it. However, the complete rebuild takes place only when you change the server side code. For any client changes, the change is almost instantaneous.
You can try some workarounds by removing some packages from meteor but they will affect debugging.
There is a great thread on this issue on Meteor's Github Issue section. You can find it here
Also, you may consider using WebStorm as it is the only IDE with built-in meteor support. May help you speed up your dev time.
UPDATE: You may try using import functionality in Meteor 1.4 to define file dependencies. Also, have a look at this package
I installed Meteor (p.s I'm new to app developement) onto my laptop (running Windows 10) and have created an app for which I have downloaded packages for (materialize, accounts-ui and passwords). The problem that I'm facing is that whenever I make changes to the html,css or js files, I get "client-modified" on my terminal, but it never actually refreshes. It's just stuck there in a loop after no matter how many modifications I make. Is this due to the current Meteor version I have installed (1.2.1)?
=> Client modified -- refreshing
This happened to me also, yesterday and today, that's how I found this question.
My observations are:
check if the app is running and working despite the apparent hang. If it does, try making a simple change in a html or template file and see if the app auto-updates. It did for me, but your mileage may vary.
If it gets too annoying, you can always just kill and restart the app. Shouldn't take too long. Check if this improves the situation.
If 2. does not help you may try "meteor reset" to clean things up, but ONLY if you just started developing your app and don't care about losing any app data (MongoDB get's wiped along with the rest of the /.meteor/local folder)
Hope the above helps...
Norbert
I've recently started working on Grunt and figured out how to use its built-in live reload feature. I am using a WordPress theme to develop and asked the developers if they could better include the Grunt live reload functionality into the theme. They would insist on using the application instead (which isn't grunt). They said it would be dangerous to use as you should remember to remove the file from the production environment when you're done, even though I recommended a simple way to make sure it only stays in the development environment (which went ignored). I'm just curious as to what's the big disadvantage in using the grunt live reload vs the application? To me it seems better to keep it all with Grunt (by adding a couple of extra lines of code) instead of adding another tool to my workflow, granted it may be more dedicated to live reloading.
I work with grunt-contrib-watch with the livereload in almost every project and I didn't see any disantages so far.
The only problem that I can point out, is that livereload should be used only for lighter tasks or it can be a bit annoying if you're making him track heavy tasks.
It seems to me that your coworkers are being a skeptical for no reason, if you're not using grunt or gulp, putting them on your projects might be a huge improvement.
I am developing a meteor application. I noticed that the meteor server sometimes suddently crashes, this makes me think that it might not be optimized for production.
In a production environment, should I consider to add/remove some packages? Which one? And what are the best settings? I just want to make sure to have a reliable server that stay up all the time.
Have you taken a look at meteor up yet? It will set up a production quality server for you. I've used it for several production applications and it works great.
As far as adding/removing packages goes, I've never ran into any problems with installed packages running on production. A couple of my apps have about a dozen or so packages installed. But if you suspect that a package might be causing the problem, I would go to atmosphere and search for your packages and make sure that they haven't been flagged. You'll see a bright red flag next to the package name if it's been flagged by the community as "not working".
Maybe also check for issues on GitHub.
If you do decide to use meteor up, after your app has been uploaded to the server, you can check the log s for any problems.
mup logs -f
So, I'm working on a Mac Mini, using WebStorm to fuss with Meteor apps. I'm finding that WebStorm tends to get sluggish, and is constantly trying to index things. I have 4 gigs of RAM, of which 791M seem to be allocated to WebStorm at any one time. My disk drive is 500GB, and I make sure there's always at least 20% to 30% free space.
So, a few questions... is it Meteor's bundle process that's causing WebStorm to do the indexing? Is there any way to optimize the indexing? Make it run less frequently? Ignore the .meteor directory, perhaps? Is 20% of available RAM an appropriate amount to allocate to WebStorm for Meteor development? Are there any other things that people can recommend to optimize WebStorm so it's not so sluggish?
Thanks in advance for any recommendations!
As #Martin said - exclude the directories where Meteor stores it compiled files: .meteor\local and .meteor\meteorite (when using meteorite).
To have Meteor suggestions / ... add the Meteor source as an external library: /usr/lib/meteor/packages/. I'm using PhpStorm as well and add the path to the PHP include path (doesn't matter it's not a PHP-library).
When adding it as a JavaScript Library in the project settings the directory structure gets lost and you have to repeat this when upgrading meteor.
I'm using PHPStoem for my meteor development and I am having the same issue as you do. I guess the engine in PHPStorm is identical to WebStorm...
I'm unsure if increasing the amount of RAM available to the IDE actually will have any effect. The issue is related to the IDE re-indexing the folder-tree whenever changes are made to any file(s) in the tree.
When meteor is running and changes is made to a file, meteor is bundling the whole application into the .meteor folder why the tree is re-indexed.
I haven't tried it out yet, but I guess what actually will help is to add the .meteor-folder to the ignore list so it wont be re-indexed every time a file-change happens.