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).
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.
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.
- Wrapping URLs in Console.url. Making Console.url not word-wrap URLs,
on the off-chance that a URL could be wrapped.
- Creating a doNotWrap function on the Console. Call this on things that
are not commands or URLs, but still should not be wrapped.
- fixing minor mistypes, removing a comment about the dev bundle on the
Windows branch.
Includes the following changes to Console.js:
- Console.info, Console.warn, Console.debug and Console.error now automatically
line-wrap the output to 80 characters, or the width of the terminal screen (if
known). This is in line with our current style guide on how things should be wrapped!
- Sometimes, there are parts of text that we don't want to line-wrap. For example, if we are
telling the user to run 'meteor long-command --with --options' we don't want to
have a newline in the middle of that! Wrap those commands in Console.command, like
this:
Console.info("something and then run", Console.command(command), "and then");
This also makes them bold if chalk is on, as a nice bonus. So, if we ever turn
chalk back on, the bolding of commands will be more consistent.
- Sometimes, there is bulkier output that we don't want to format at all, including
line-wrapping: log snippets, stack traces, JSON output, etc. In that case, we can use
Console.rawInfo, Console.rawError, Console.rawWarn and Console.rawDebug. Don't use
Console.command inside the raw* functions! It won't be processed (at all).
- There are fancier things that we can do, other than just simply wrapping things.
We can indent:
" Start here and then when wrapping
continue over here".
We frequently do this for commands, for example. In the past, we did this manually --
but we can't do this for long messages that might get wrapped, and anyway, it is
good to codify this instead of counting spaces. Allows us to be better about consistency,
for example.
- We can also add a bulletPoint, which is a small notice in the beginning that looks like
this:
" => Start here and then when wrapping
continue below the bulletPoint".
Since it is a elss intuitive option, I have wrapped most of the time that we use a
bulletPoint into helper functions on the Console.js.
- Some common bulletpoints that we use are:
ASCII Checkboxes (Console.success)
ASCII X-s (Console.failWarn and Console.failInfo)
=> (Console.arrowError, Console.arrowWarn, Console.arrowInfo)
WARNING (Console.labelWarn)
The => are sometimes indented, so they take an optional indent argument, showing how
many spaces to indent by.
The wrapper interface would be less complicated, if there was a more unified conceit behind our
terminal messages. If there is one, it is not documented. My hope is that, in many cases,
moving these to Console will make it easier for someone with great product sense to
clean up our terminal messages. It will also make it easier to write such messages, since
it will be easier to follow an accepted standard.
In the codebase outside of Console:
- Went through and looked at our use of Console.error/info/etc, replacing with rawError/etc
whenever approporiate.
- Went through and modified most of 'stdout' and 'stderr' calls to use the new functions.
I made an exception for stuff that doesn't want a new line at the end, or otherwise does
weird things (ex: print user logs directly), on the basis that, at this juncture, it is
better to be safe than to be sorry.
- Long messages no longer need to break the code style guide by ignoring indentation rules.
Fixed that where approporiate.
- Fixed the tests! A number of our stock messages are actually longer than 80 chars.
- Personal favourite: The Android license agreement is now line wrapped! Much better experience.
- There is some more work to do on:
- longform help (currently comes with built-in linebreaks, would have to change the entire
mechanism for how that works)
- Buildmessage sometimes has headers that start with =>, but they are short. I didn't want to
pass wrapper options all the way to main.captureOrExit before merging the rest of this and
making sure that we like it. Since these messages are fairly short, I don't think that's
likely to be a serious problem.
I hope that this makes life easier for us in the future! No more counting chars, no more breaking
the style guide. Better experience for users with wider terminals (or even shorter terminals!).
Let's give this a try.
For freshly created apps, this commit reduces the time required to start
the development server from 4.6s to 2.5s on my machine.
Not calling findMongoAndKillItDead unless Mongo fails to start shaves off
a few hundred milliseconds, too.
Fixes#3010.
This reimplements functionality that had been removed as part of the
`isopack-cache` branch refactoring.
Information about package changes is encapsulated inside a
PackageMapDelta object on the ProjectContext. It is the responsibility
of the command that prepares the ProjectContext to choose to call
projectContext.packageMapDelta.displayOnConsole at the appropriate time
if it wishes to display changes.
Part of #3006.
Previously, all progress display was turned off after the app’s initial start, so no progress would be displayed on restart due to server code change.
Now, we enable/disable progress display from inside the loop that re-runs the app on change.
Remove the “suppressDisplay” approach to hiding the spinner when there’s an error building the app, because it didn’t work on rebuilds, only the first build. Better to just call enableProgressDisplay(false) and hope for the best like we do elsewhere.
We don't have a way to HCP a changed set of plugins or platforms, so
just exit and ask the user to re-run. There are probably some cases
where we don't have to exit (e.g. if you add the android platform, we
probably don't need to exit out of 'meteor run ios'), but we exit in all
cases for simplicity.
The server sends hot code push updates to mobile clients with ROOT_URL
and DDP_DEFAULT_CONNECTION_URL taken from the MOBILE_ROOT_URL and
MOBILE_DDP_URL environment variables. These are set by the main meteor
process when it starts the app runner.
Summary:
The `node-inspector` NPM package was added to the dev_bundle by this
recent commit: 64a624ae5c
Task: https://app.asana.com/0/15750483766338/16241466809965
Test Plan:
Add `debugger` statements to server code, run `meteor debug`, visit the
node-inspector URL in a browser, continue the application, and verify that
the debugger stops at the `debugger` statements that were set.
Reviewers: nim, slava, emily, avital, dgreenspan
CC: sashko
Differential Revision: https://phabricator.meteor.com/D827
We still use localhost as DDP_DEFAULT_CONNECTION_URL for mobile builds
if another host isn't provided; we just don't want localhost to
overwrite an unspecified host for the proxy to bind to.
Fixes#2596.
Port a simplified version of Meteor.EnvironmentVariable and
Meteor.bindEnvironment to fiber-helpers.js to deal with this.
Identify uses of fiberHelpers.inFiber and switch them to either
fiberHelpers.bindEnvironment (if the callback they are wrapping is
semantically "part of" the context that creates the callback) or
fiberHelpers.inBareFiber (otherwise).
Without this, concurrency was causing the wrong buildmessage message
sets and jobs to be active when builds yielded.
This is only intended for testing. No data is preserved from one run to
the next, and if any mongod exits for any reason, the rest are killed;
there is no mongod restarting.
It takes a while (~20 seconds) to start up because it waits for the
replset to be ready.
Doing so reveals a deadlock in the stop code (which causes self-test to
fail, yay). Fix it by trying harder to not stop the (all or app) runner
until after the app runner has processed the "hey you should stop"
return false from onRunEnd.
If you happen to introduce a circular require into the stack, this
object will be undefined.
Instead, hang on to `require('./run-log.js')`, which is the exports
module which does get filled in later.
The rationale: RunLog is an object that is hardcoded around managing two
other singletons: stdout and stderr. Having multiple RunLogs wouldn't
work well without improving RunLog to have the ability to control other
streams.
We'd like to be able to use RunLog from other places in the tool, most
notably from code called from bundler (while running an app) such as the
npm updater. But threading a RunLog object through that code is
difficult (especially as bundling takes a detour through
release.current.library).
- Exit with failure if proxy starts to listen. Previously, we got stuck
inside ProxyRunner.start(), and since we weren't waiting on any IO
we'd exit 0! (The existence of a yielded fiber is not sufficient to
block Node exit.)
- Don't print various bits of startup text if we are stopped midway.
- Stop main Runner immediately if proxy or mongo runners invoke
onFailure, rather than waiting for wait to be called and return.
- Ensure that a few Futures don't get return called on them multiple
times.
- Ensure we don't try to call close() on the proxy's TCP server if it
failed to listen in the first place.
