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.
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 am trying to use TingoDB instead of MongoDB in a Meteor application I wrote for easier deployment.
I have been looking at the answer given here Meteor without mongo
However, this isn't proving to be so easy. For one thing, I would very much like to try and use (and debug) TingoDB in my development environment, not a bundled "production" environment. Hopefully when I bundle it for production the new "mongo-livedata.js" would be included too.
My biggest issue so far is that I have NO idea (and I've tried tracing and poking around Meteor) where the devil Meteor is getting the "correct" mongo-livedata.js package. I am hoping to be able to somehow "override" said package so I can "hack" away on it in safety and only for the single application I need it for. So far where Meteor is loading this for development has eluded me greatly. Let alone how I can, for this application, safely override it.
This is Meteor 1.1.02 -- the platform I am developing on is Mac OS X but I don't think that makes too much of a difference.
TIA!
Update: Using demeteorizer found the file in question now (mongo.js) and the similar code. However, changing over to TingoDB has now made the application non-reactive to data changes, rather the reason I was using Meteor in the first place. No idea why it's no longer reactive. :(
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.
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.
So I've recently setup a LEMP server and have managed to work may way through some of the configurations. I'm now to the point where I can begin writing php scripts and building basic pages. Looking at the php5-fpm wiki there aren't any pages discussing any changes I should expect as far as php scripts and such are concerned, only installation/configuration settings.
Is everything beyond the installation/configurations steps business as usual? From the point of view of a php developer what changes should I expect/make? How can best take advantage of the fpm version (in the php code, not module/system configurations)? I'm focused on comparing well-written php in both cases.
When I made the switch myself, I got to know a few perks about this kind of setup, such as APC file upload progress does not work out of the box (and you're better off using something else, such as nginx-progress-upload and/or JS File API); Some header names might have changed (prepending HTTP_); and a new and very useful function called fastcgi_finish_request.
For more information, though, look around the PHP-FPM Manual.
Only major gotcha I can think of is that some functions in the pcntl extensions, such as pcntl_fork, are not supported when running under FPM. (However, they're not supported under mod_php either, so this shouldn't come as too much of a surprise.)