This strategy was suggested by @glasser after we realized just how
hopeless it is to probe the file system to test pathwatcher:
https://github.com/meteor/meteor/issues/3285#issuecomment-67296961
I've made some attempt to de-duplicate these events (since we're
effectively watching twice now), but we have other mechanisms for dealing
with bursty file change events, so these measures do not need to be
completely bulletproof.
Fixes#3284 (again).
This also un-breaks soft refresh for troposphere packages:
previousIsopack was accidentally being set to an
{isopack,pluginProviderPackageMap} object, and so the "can we reuse the
previous one" check was never actually passing.
Running the two versions of the test in parallel is safe because they run
in separate processes, and a good idea because it cuts the time taken by
the test in half, from 36sec to 19sec.
Conflicts from devel:
tools/tests/old.js
Previously we were testing pathwatcher.watch by creating a file in
.meteor/local, but developers using Vagrant VMs often mount .meteor on a
different (non-network) file system, for Mongo's sake.
Writing the file directly in the app directory increases the likelihood
that it will interact with pathwatcher in the same way as other source
files the developer will be editing.
Conflicts from devel:
tools/safe-pathwatcher.js
Typically, there is a delta due to adding the test slice of the
published package, but there's no reason to tell the user about this or
save it in .meteor/versions.
Specifically, we only compile them if there's a cordova platform in the
current project, or if we are publishing the package.
(Ideally, we wouldn't require every published package to have
web.browser and web.cordova unibuilds --- we'd just publish a 'web'
unibuild unless there's actually a difference between the two. But we
are not there yet.)
This adds an extra flag to isopack-buildinfo.json, so that we know to
rebuild all the isopacks when we add the first cordova platform (or
remove the last cordova platform).
The implementation around publish is a little clunky; if you're in a
non-Cordova app and run meteor publish, it will rebuild all the packages
with web.cordova, and the next time you prepare the app it will rebuild
them again without it. It does work though.
Fixes#3274.
Previously, we would register the circular dependency error properly
with buildmessage, but then try to build the package with a circular
dependency anyway, leading to a crash.
Fixes#3280.
This will refresh the status bar more often and make the build tool more
responsive to signals.
Now that yield uses setImmediate, this has minimal effect on
performance.
- Lower STATUS_INTERVAL_MS from 500 to 50. Note that we were effectively
doing 150 or 100 anyway: the _pollFiber was polling every 100, and the
nudged _throttledStatusPoll was actually throttling at the default of
150, not 500, because the Throttled constructor was being invoked
incorrectly (without the named 'interval' option).
- Use the same throttler for _pollFiber and nudge.
Fixes#2846. Fixes#2847. Fixes#2979.
Errors in the build process that could be fixed by refreshing the
catalog now cause the catalog to refresh, assuming we have not already
refreshed it recently and that we are not offline.
These commands now don't need to refresh at startup: remove, run, debug,
create, build, bundle, deploy, test-packages, rebuild, and self-test
It should be OK for create to throw SpringboardToLatestRelease even
without refreshing, since release.latestKnown is still something we know
about.
