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.
AppRunner.stop needs to be able to cause any Future which the AppRunner
is waiting on to return, so that it can get back to the top level of its
loop and return. (This is because for some reason it is important that
AppRunner.stop does not return until the app is guaranteed to be
stopped.) This had not been the place for the injected "wait for mongo
to start up before running the AppProcess" future.
This also means we can't use f.future() any more, because that code
assumes that it is the only code allowed to resolve its future (it
unconditionally resolves the future when the wrapped function returns,
which is an error if it is already resolved).
This is tested by 'run errors' which was failing. Also, the test should
only expect 2 unexpected exit code messages, not 3, since we don't print
the message the first time which didn't have a kill before it.
No need to introduce the LayeredCatalog anywhere it's not needed.
Simplify some more things about LayeredCatalog:
- remove unused containingCatalog link from localCatalog to
layeredCatalog
- because of that, simplify LayeredCatalog initialization to occur after
localCatalog (no more circular references required)
- drop some other dead LayeredCatalog methods
If you Blaze.remove a View that is a template rendered by Blaze.renderWithData, or included with an implicit “with” as in `{{> myTemplate someData}}`, Blaze will now remove the DOM of the template, and also remove the implicit “with” (in both cases).
As background, Blaze.remove only works on Views that were attached directly under a DOM element, not inside another View. Blaze.render always attaches the resulting View directly under a DOM element, but Blaze.renderWithData creates a “with” View around the template View. Previously, you could Blaze.remove the “with” View (which is returned by renderWithData), but if you got access to the template’s View some other way and tried to remove it directly, nothing would happen. Now, the correct thing happens (the View is destroyed and the DOM is removed).
In the future, we should consider whether Blaze.remove should work on arbitrary Views, not just Views attached under a DOM element.
