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.
Link to Meteor website was broken and there were 2 links which looked
like one. Replaced with a link to the list of packages in the Meteor
repository to give the best currently available overview of the parts
of Meteor.
* Update CoffeeScript to 1.11.0, which supports modules; update check for whether to pass CoffeeScript’s output to Babel to look not just for backticks, but also for `import`, `export` and `function*`, the current ESNext features output by CoffeeScript
* Add tests for imported modules using CoffeeScript’s new native import statement
* Test that CoffeeScript native export statements work, by importing something exported by such a statement
* Improve regex
* Optimize regex
* 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
New policy: pull requests for Meteor releases (e.g. release-1.4.2) will
now target the master branch instead of devel, and we will merge the
release branch back into devel periodically (say, every time we release a
new beta or release candidate).
All other pull requests should continue to target devel.
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.
This will allow publishing `boilerplate-generator` independently from
Meteor, so that Meteor 1.4 developers can update immediately by running
`meteor update boilerplate-generator`.
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.
