Summary:
Instead of expecting the child process to figure out where the
`.meteor/local` directory is, we now tell it explicitly via the
`METEOR_SHELL_DIR` environment variable.
Fixes#3437.
Test Plan:
Run `meteor shell` in a separate terminal and see that it still connects
to an app running from the same app directory.
Reviewers: glasser
Reviewed By: glasser
Differential Revision: https://phabricator.meteor.io/D11
This commit moves parent pid process from the webapp package to the boot
script. This means that daemonized apps without webapp will also exit
when the runner exits, if run from the runner. (For example, several
self-tests such as 'autoupdate' no longer leak node processes.) This is
controlled via the $METEOR_PARENT_PID environment variable instead of
from command line arguments, in order to make fewer assumptions about
how Meteor apps process arguments.
This also drops the old --keepalive support (which already has stopped
being used by the dev mode runner or any MDG deployment platforms).
Neither --parent-pid nor --keepalive were documented beforehand, and
--keepalive was already deprecated before 1.0.
These flags used to also incidentally trigger printing the LISTENING
line; this is now controlled by $METEOR_PRINT_ON_LISTEN.
Fixes#3315.
Because that's where the SIGUSR2 handler is.
Arguably this should be some more abstract interface where packages can
say "I have a handler for client refresh", but whatever.
Fixes#3365.
This will be useful when we want to be smart with windows file paths later
Also, all of the file calls are asynchronous with fibers now, which comes with
many benefits.
This is a combination of 23 commits. Original messages:
Wrap a large number of fs calls inside files.*
Convert a few more fs calls to files.*
More moving fs.* to files
Implement read/write streams and open/read/close
Get rid of fs from auth.js
Remove fs and unused imports from catalog-local and catalog-remote
Remove unused imports from catalog.js
Replace a whole lot of fs calls
Fix error
Migrate a lot more fs. calls to files.
Add a temporary symlink method
Convert old test to files.*
Use files.pathX instead of path.x everywhere
Replace path.x to files.pathX in tests
Small fixes to files.js and one rename
Make cleanup run in a fiber
Make wrapping functions take function name in case we need it
Add some timeouts and stuff to HCP tests
wrapFsFunc also makes a sync version of the function
Sometimes you just don't want to yield!
Make sure JsImage readFromDisk doesn't yield
Remove unused imports from npm test
Change order of test now that some things don't yield
Fix missing files import, and add a debug error printout
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.
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.
a platform change often creates a plugin change, so we should mention
the more major change first. also helps with "meteor exits when cordova
platforms change" self-test
It's still in unmigrated commands.
Remove tropohouse's catalog. It was there to stop you from downloading
local packages but downloadPackagesMissingFromMap does that based on the
PackageMap now.
On-disk cache will be replaced by a new class.
Soft refresh was an optimization that wasn't actually very optimized in
0.9.0; it used to only have to look at an in-memory WatchSet and check
those files, but in 0.9.0 it also re-read the whole isopack. Will add
this optimization back in if necessary and safe later.
ie, make it prepend METEOR@ if necessary.
(We DON'T do that in the pre-springboard call in main because that one
might be telling us to springboard to a pre-0.9.0 release!)
Solves a bunch of issues like the previous commit where, if
.meteor/release just says "0.9.4", you get weird behavior.
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.
(…due to a server-side code change)
Restarting the server can take a while (30 seconds for one particular app), so it’s nice to at least print when we start doing it. Soon there will be progress displays during it, too (when we add more of them to `meteor run`).
We lose the opportunity to coalesce server restarted messages, as in `Meteor server restarted (x2)`, but adding any sort of progress display also does that.
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.
Summary:
Invoking `meteor shell` starts an interactive REPL for evaluating server-side code.
Shell commands are evaluated in the server process, so the shell's input and output have to be piped through a socket from/to the parent process that runs the `meteor shell` command. This separation accounts for most of the complexity of this diff, but the end result is pretty seamless: tab completion, history, ctlr-c and ctrl-d, etc. all work as expected.
Task: https://app.asana.com/0/15750483766338/16576093991355
Test Plan: Run `meteor run` in one terminal and `meteor shell` in another, evaluate some commands, and verify that the commands seem to be running the context of the server process. Also check tab completion and history, and ensure that the server is running simultaneously with the shell.
Reviewers: dgreenspan, avital, slava, emily, nim, sashko
CC: sashko
Differential Revision: https://phabricator.meteor.com/D837
