We try to kill any mongod processes before starting new ones, but this
change kills it when the development server shuts down, too.
Killing mongo on shutdown is particularly important for tests that run
meteor multiple times in a row, and for whatever reason fail to find and
kill running mongod processes on startup, e.g. because the --port has
changed (#7563).
This comment by @glasser seems to suggest this is a reasonable idea:
https://github.com/meteor/meteor/issues/2182#issuecomment-45685614Fixes#2182 and possibly other related bugs.
* Prevent running sudo meteor run it on Unix
Prevent running sudo meteor run it on Unix
Fix for all commands
remove empty line
Revert "Prevent running sudo meteor run it on Unix"
This reverts commit d2867561bb6fb1b259a59556628b56a64c677a0b.
improve PR
improve PR
improve PR
fix PR
* improve PR
* fix PR
* fix PR
* fix PR
Even though I think the fight is a bit futile, it is considered best practice to have newlines at the end of all files. At the request of meteor/meteor#7786, this commit adds newlines to the end of the new app skeleton `.gitignore` file. These skel files are used when generating new meteor apps so this avoids perpetuation of this problem into futrue generations. ;)
In an effort to beef up this PR, I also took the liberty of fixing the few other Meteor files which were lacking newlines (all `.gitignore` files)
Closesmeteor/meteor#7786
This saves a potentially large amount of work by the ImportScanner and the
Resolver during makeServerTarget, because it means we no longer have to
scan and resolve modules to build a server bundle as a backup for native
Node evaluation.
I've attempted this optimization before, but it wasn't really safe until
I fixed some obscure bugs that caused module.useNode() to fail during
`meteor test-packages` (see recent local-test:-related commits).
Revert "Write node_modules metadata as single strings."
This reverts commit f74975d0df.
Packages published with multiple node_modules directories won't be
loadable by versions of Meteor before 1.3, because older versions of
Meteor don't understand object-valued isopack "node_modules" fields, but
the vast majority of Meteor developers are now using either 1.3 or 1.4.
Typically all outstanding watchers will be closed when the development
server restarts, but we can save a lot of effort if they survive the
restart, for the small cost of keeping them open for an extra 30sec.
For the galaxy-server application, this reduces the time spent in
watch.isUpToDate from six seconds to a little over second. Of course we
should also try to call it less often, but making it cheaper helps!
For the galaxy-server application, this reduces the time taken to
determine production node_modules from 1400ms to 120ms.
As another optimization, we could record the hashes of all the
package.json files encountered in this scan, and return the same set of
production package names if those hashes have not changed, though the
benefits may not be worth the additional complexity.
Now that the blaze submodule is mounted inside the packages/non-core/
directory, it appears that we no longer have to mention it explicitly in
the localPackageSearchDirs array.
After recent discussion on https://github.com/meteor/meteor/issues/7401,
@glasser and I think the relatively obscure benefit of --no-bin-links is
outweighed by the problems it causes for packages whose rebuild scripts
need executable scripts installed in the node_modules/.bin/ directory.
