meteor/tools/cli/help.txt

>>>
(the first line of each entry is the summary for autogenerated command lists)
Usage: meteor [--release <release>] [--help] <command> [args]
       meteor help <command>
       meteor [--version] [--arch]

With no arguments, 'meteor' runs the project in the current
directory in local development mode. You can run it from the root
directory of the project or from any subdirectory.

Use 'meteor create <path>' to create a new Meteor project.

Commands:
{{commands}}

See 'meteor help <command>' for details on a command.


>>> run
[default] Run this project in local development mode.
Usage: meteor run [target..] [options]

Searches upward from the current directory for the root directory of a
Meteor project, then runs that project in local development
mode. You can use the application by pointing your web browser at
localhost:3000. No internet connection is required.

Whenever you change any of the application's source files, the changes
are automatically detected and applied to the running application.

The application's database persists between runs. It's stored under
the .meteor directory in the root of the project.

If you have added a platform to your app with 'meteor add-platform', you can
pass one of the following targets as an argument to this command.

Targets:
  android          Run on the Android emulator.
  android-device   Run on a connected Android device.
  ios              Run on the iOS simulator.
  ios-device       Open Xcode with the iOS project for this app, where you can
                   run your app on a connected iOS device.

Options:
  --port, -p       Port to listen on (instead of the default 3000). Also
                   uses port N+1 and a port specified by --app-port.
                   Specify as --port=host:port to bind to a specific interface.
  --debug-port     Specify a port to enable server-side debugging. The
                   server will be paused at startup, waiting for incoming
                   connections from debugger clients on the specified port.
  --mobile-server  Location where mobile builds connect to the Meteor server.
                   Defaults to your local IP and the port that the Meteor
                   server binds to. Can include a URL scheme (for
                   example, --mobile-server=https://example.com:443).
  --production     Simulate production mode. Minify and bundle CSS and JS files.
  --raw-logs       Run without parsing logs from stdout and stderr.
  --settings, -s   Set optional data for Meteor.settings on the server.
  --release        Specify the release of Meteor to use.
  --verbose        Print all output from builds logs.
  --no-lint        Don't run linters used by the app on every rebuild.
  --no-release-check            Don't run the release updater to check for new releases.
  --allow-incompatible-update   Allow packages in your project to be upgraded or
                   downgraded to versions that are potentially incompatible with
                   the current versions, if required to satisfy all package
                   version constraints.

>>> debug
Run the project, but suspend the server process for debugging.

Usage: meteor debug [--debug-port <port>] [run options]
       meteor run --debug-port <port> [run options]

The server process will be suspended just before the first statement of
server code that would normally execute. In order to continue execution of
server code, use either the web-based Node Inspector or the command-line
debugger (further instructions will be printed in the console).

The easiest way to set breakpoints is to use the `debugger` keyword:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger

The options for 'meteor debug' are identical to those for 'meteor run',
with one addition:

Options:
  --debug-port   Port on which the server process debugger should listen
                 for incoming connections from debugging clients, such as
                 node-inspector (default 5858).


>>> create
Create a new project.
Usage: meteor create [--release <release>] <path>
       meteor create [--release <release>] --example <example_name> [<path>]
       meteor create --list
       meteor create --package [<package_name>]

Make a subdirectory named <path> if it doesn't exist and create a new Meteor app
there. You can pass an absolute path, relative path, or '.' for the current
directory.

With the --package option, creates a Meteor package instead of an app. If you're
in an app, the package will go in the app's top-level 'packages' directory;
otherwise it will be created in the current directory.

The app will use the release of Meteor specified with the --release
option, or the latest available version if the option is not specified. (A
package created in an app, will be created using the application's version of
meteor and a package created outside a meteor app will use the latest release).

You can pass --example to start off with a copy of one of the Meteor
sample applications. Use --list to see the available examples. There are
currently no package examples.

Options:
  --package  Create a new meteor package instead of an app.
  --example  Example template to use.
  --list     Show list of available examples.


>>> update
Upgrade this project's dependencies to their latest versions.
Usage: meteor update
       meteor update --patch
       meteor update --release <release>
       meteor update --packages-only
       meteor update [packageName packageName2 ...]

Updates the meteor release, and then, if applicable, updates the packages
used by the app to the latest versions that don't cause dependency
conflicts with other packages in the app.

Passing the --patch argument will update to the latest patch, if such exists.
Patch releases contain very minor changes, usually bug fixes. Updating to
the latest patch is always recommended. This will try to not update non-core
packages unless strictly nessessary.

Passing the --release argument will force update to a specific release of
meteor.  This will not update non-core packages unless strictly nessessary. It
is also possible that some packages cannot be updated to be compatible with the
new release. If that happens, the app will not build until dependencies on those
packages are removed.

Passing --packages-only will try to update non-core packages to their latest
versions. It will not update the version of meteor. To update individual
packages (for example: 'foo:awesome') pass in their names instead, with no
options. ('meteor update foo:awesome').

Options:
  --packages-only  Update the package versions only. Do not update the release.
  --patch          Update the release to a patch release only.
  --release        Update to a specific release of meteor.
  --allow-incompatible-update   Allow packages in your project to be upgraded or
                   downgraded to versions that are potentially incompatible with
                   the current versions, if required to satisfy all package
                   version constraints.


>>> admin run-upgrader
Execute a specific upgrader by name. Intended for testing.
Usage: meteor admin run-upgrader <upgrader>

Runs a specific upgrader on the current app. This is for testing
internal functionality of Meteor.


>>> add
Add a package to this project.
Usage: meteor add <package> [package..]

Adds packages to your Meteor project. You can add multiple
packages with one command. To query for available packages, use
the meteor search command.

Optional version constraints can be added. Running `meteor add package@1.1.0`
will add the package at version 1.1.0 or higher (but not 2.0.0 or higher).
If you want to use version 1.1.0 exactly, use `meteor add package@=1.1.0`.
You can also 'or' constraints together: `meteor add 'package@=1.0.0 || =2.0.1'`
means either 1.0.0 (exactly) or 2.0.1 (exactly).

To remove a version constraint for a specific package, run "meteor add" command
again without specifying a version. For example above, to stop using
version 1.1.0 exactly, run `meteor add package`.

Options:
  --allow-incompatible-update   Allow packages in your project to be upgraded or
                   downgraded to versions that are potentially incompatible with
                   the current versions, if required to satisfy all package
                   version constraints.


>>> remove
Remove a package from this project.
Usage: meteor remove <package> [package..]

Removes a package previously added to your Meteor project. For a
list of the packages that your application is currently using, see
'meteor list'.

Options:
  --allow-incompatible-update   Allow packages in your project to be upgraded or
                   downgraded to versions that are potentially incompatible with
                   the current versions, if required to satisfy all package
                   version constraints.


>>> list
List the packages explicitly used by your project.
Usage: meteor list

Lists the packages that you have explicitly added to your project.
This will not list transitive dependencies.

>>> add-platform
Add a platform to this project.
Usage: meteor add-platform <platform> [platform..]

Adds platforms to your Meteor project. You can add multiple
platforms with one command.

Available platforms:
  server
  browser
  android
  ios (on OS X only)

Currently, the server and browser platforms are present in every
Meteor project and cannot be removed.

`meteor run` by default runs the server and browser platforms.
After adding a mobile platform, you can use 'meteor run <mobile-platform>'
to run on a mobile device or emulator. 'meteor build' will always build
the project for every added platform.

>>> install-sdk
Installs SDKs for a platform.
Usage: meteor install-sdk <platform>

Installs the SDK for a platform; will also verify that the platform
requirements are met.

Available platforms:
  android
  ios (on OS X only)

>>> remove-platform
Remove a platform from this project.
Usage: meteor remove-platform <platform> [platform..]

Removes a platform previously added to your Meteor project. For a
list of the platforms that your application is currently using, see
'meteor list-platforms'.

>>> list-platforms
List the platforms added to your project.
Usage: meteor list-platforms

Lists all of the platforms added to your project.

>>> configure-android
Run the Android configuration tool from Meteor's ADK environment.
Usage: meteor configure-android

Runs the Android configuration tool from Meteor's ADK environment.
This command can be useful to configure AVDs, HAX and update the SDK.

>>> bundle
Deprecated command. Use 'build' instead.
Usage: meteor bundle <output_file.tar.gz>

Pack this project up into a tarball.

This command has been deprecated in favor of 'meteor build', which allows you to
build for multiple platforms and outputs a directory instead of a single
tarball. See 'meteor help build' for more information.


>>> build
Build this project for all platforms.
Usage: meteor build <output path> [--debug] [--directory] [--server-only]
          [--mobile-settings settings.json] [--server http://example.com:3000]

Package this project up for deployment. The command outputs a directory with
builds for all platforms in this project.

If you have added mobile platforms to your project with the
'meteor add-platform' command, then the output directory will contain
subdirectories named 'android' (with the APK bundle and Android project
source) and/or 'ios' (with the Xcode project source).

Pass `--server-only` to skip building mobile apps, but still build the
'web.cordova' client target so the server can support hot code push
for Cordova apps.

The output directory will contain a tarball that includes everything necessary
to run the application server. (See README in the tarball for details.)

Options:
  --debug             Build in debug mode (don't minify, etc).
  --directory         Output a directory (rather than a tarball) for the
                      application server bundle. If the output location exists,
                      it will be recursively deleted first.
  --server-only       Skip building mobile apps even if mobile platforms have
                      been added.
  --mobile-settings   Set optional data for the initial value of Meteor.settings
                      in your mobile application. A new value for
                      Meteor.settings can be set later by the server as part of
                      hot code push.
  --server            Location where mobile builds connect to the Meteor server.
                      Defaults to localhost:3000. Can include a URL scheme
                      (for example, --server=https://example.com:443).
  --architecture      Builds the server for a different architecture than your
                      developer machine's architecture. Valid architectures
                      include os.osx.x86_64, os.linux.x86_64, and
                      os.linux.x86_32.
  --allow-incompatible-update   Allow packages in your project to be upgraded or
                      downgraded to versions that are potentially incompatible
                      with the current versions, if required to satisfy all
                      package version constraints.


>>> lint
Build this project and run the linters printing all errors and warnings.
Usage: meteor lint

Run through the whole build process for the app and run all linters the app
uses. Outputs all build errors or linting warnings to the standard output.

Options:
  --allow-incompatible-update   Allow packages in your project to be upgraded or
                      downgraded to versions that are potentially incompatible
                      with the current versions, if required to satisfy all
                      package version constraints.


>>> shell
Launch a Node REPL for interactively evaluating server-side code.

Usage: meteor shell

When `meteor shell` is executed in an application directory where a server
is already running, it connects to the server and starts an interactive
shell for evaluating server-side code.

Multiple shells can be attached to the same server. If no server is
currently available, `meteor shell` will keep trying to connect until it
succeeds.

Exiting the shell does not terminate the server. If the server restarts
because a change was made in server code, or a fatal exception was
encountered, the shell will restart along with the server. This behavior
can be simulated by typing `.reload` in the shell.

The shell supports tab completion for global variables like `Meteor`,
`Mongo`, and `Package`. Try typing `Meteor.is` and then pressing tab.

The shell maintains a persistent history across sessions. Previously-run
commands can be accessed by pressing the up arrow.


>>> mongo
Connect to the Mongo database for the specified site.
Usage: meteor mongo [--url]

Opens a Mongo shell to view or manipulate collections.

If site is specified, this is the hosted Mongo database for the deployed
Meteor site.

If no site is specified, this is the current project's local development
database. In this case, the current working directory must be a
Meteor project directory, and the Meteor application must already be
running.

Instead of opening a shell, specifying --url (-U) will return a URL
suitable for an external program to connect to the database. For remote
databases on deployed applications, the URL is valid for one hour.

Options:
  --url, -U  return a Mongo database URL


>>> reset
Reset the project state. Erases the local database.
Usage: meteor reset

Reset the current project to a fresh state. Removes all local data.


>>> deploy
Deploy this project to Meteor.
Usage: meteor deploy <site> [--settings settings.json] [--debug] [--delete]

Deploys the project in your current directory to Meteor's servers.

You can deploy to any available name under 'meteor.com'
without any additional configuration, for example,
'myapp.meteor.com'. If you deploy to a custom domain, such as
'myapp.mydomain.com', then you'll also need to configure your domain's
DNS records. See the Meteor docs for details.

The --settings flag can be used to pass deploy-specific information to
the application. It will be available at runtime in Meteor.settings, but only
on the server. If the object contains a key named 'public', then
Meteor.settings.public will also be available on the client. The argument
is the name of a file containing the JSON data to use. The settings will
persist across deployments until you again specify a settings file. To
unset Meteor.settings, pass an empty settings file.

The --delete flag permanently removes a deployed application, including
all of its stored data.

Options:
  --delete, -D    permanently delete this deployment
  --debug         deploy in debug mode (don't minify, etc)
  --settings, -s  set optional data for Meteor.settings
  --allow-incompatible-update   Allow packages in your project to be upgraded or
                  downgraded to versions that are potentially incompatible with
                  the current versions, if required to satisfy all package version
                  constraints.


>>> logs
Show logs for specified site.
Usage: meteor logs <site>

Retrieves the server logs for the requested site.


>>> authorized
View or change authorized users and organizations for a site.
Usage: meteor authorized <site> [--list]
       meteor authorized <site> --add <username>
       meteor authorized <site> --remove <username>
       meteor authorized <site> --transfer <username>

Without an argument (or with --list), list the users and organizations that are
administrators for a particular site that was deployed with 'meteor deploy'

For free hosting:

With --add, add an authorized user or organization to a site. Use this to give
your collaborators the ability to work with your sites.

With --remove, remove an authorized user or organization from a site. You cannot
remove yourself. (Ask someone else who is an authorized user to do it.)

You can only add or remove one authorized user at a time.

For Galaxy:

With --transfer, transfer the ownership of the application to a new user or
organization.

Options:
  --add         add an authorized user or organization (for free hosting)
  --remove      remove an authorized user or organization (for free hosting)
  --transfer    transfer the (Galaxy) app to a new user or organization
  --list        list authorized users and organizations (the default)


>>> claim
Claim a site deployed with an old Meteor version.
Usage: meteor claim <site>

If you deployed a site with an old version of Meteor that did not have
support for developer accounts, you can use this command to claim that
site into your account. If you had set a password on the site you will
be prompted for it one last time.


>>> login
Log in to your Meteor developer account.
Usage: meteor login [--email]

Prompts for your username and password and logs you in to your Meteor
developer account. Pass --email to log in by email address rather than
by username.


>>> logout
Log out of your Meteor developer account.
Usage: meteor logout

Log out of your Meteor developer account.


>>> whoami
Prints the username of your Meteor developer account.
Usage: meteor whoami

Prints the username of the currently logged-in Meteor developer.

See 'meteor login' to log into or 'meteor logout' to log out of your
Meteor developer account.


>>> test-packages
Test one or more packages.
Usage: meteor test-packages [--release <release>] [options] [package...]

Runs unit tests for one or more packages. The results are shown in
a browser dashboard that updates whenever a relevant source file is
modified.

Packages may be specified by name or by path. If a package argument
contains a '/', it is loaded from a directory of that name; otherwise,
the package name is resolved according to the usual package search
algorithm ('packages' subdirectory of the current app, $PACKAGE_DIRS
directories, and core packages in that order). You can test any number
of packages simultaneously. If you don't specify any package names
then all available packages will be tested.

Open the test dashboard in your browser to run the tests and see the
results. By default the URL is localhost:3000 but that can be changed
with --port.

Options:
  --port, -p        Port to listen on (instead of the default 3000). Also
                    uses port N+1 and N+2.
  --debug-port      Specify a port to enable server-side debugging. The
                    server will be paused before any tests run, waiting
                    for incoming connections from debugger clients.
  --mobile-server   If running tests in an emulator or on a mobile device,
                    the location where mobile builds connect to the
                    Meteor server. Defaults to your local IP and the
                    port that the Meteor server binds to. Can include a
                    URL scheme (for example,
                    --mobile-server=https://example.com:443).
  --production      Simulate production mode. Minify and bundle CSS, JS files.
  --settings, -s    Set optional data for Meteor.settings on the server

  --ios,            Run tests in an emulator or on a mobile device. All of
  --android,        the tests for client and server will run in addition to
  --ios-device,     mobile-specific tests.
  --android-device
  --test-app-path   Set the directory in which to create a temporary app used
                    for tests. Defaults to the system's temporary directory,
                    usually /tmp.
  --verbose         Print all output from builds logs.
  --no-lint         Don't run linters used by the tested packages on every
                    test app rebuild.
>>> test
Test the application
Usage: meteor test --driver-package <driver> [options]
       meteor test --full-app --driver-package <driver> [options]

Runs tests against the application.
Will start a special app based on a test driver (specified with
--driver-package -- read more about driver packages at
http://guide.meteor.com/testing.html#driver-packages) which handles the
task of running tests and displaying the results in the browser when you
visit it.

In normal test mode, no files in your application are eagerly loaded, aside
from test files (files named *.test[s].* or *.spec[s].* placed anywhere
in your application). You can import your app's modules from within your
tests and use them as normal.

In "full app" test mode, your app is loaded as usual, and then made hidden,
and your tests can inspect and effect the running state. Test files are
loaded similarly to unit test mode, but must be called *.app-test[s].* or
*.app-spec[s].*.

Open the test dashboard in your browser to run the tests and see the
results. By default the URL is localhost:3000 but that can be changed
with --port.

Read more about testing your application in the Testing Article of the
Meteor Guide - https://guide.meteor.com/testing.html

Options:
  --port, -p        Port to listen on (instead of the default 3000). Also
                    uses port N+1 and N+2.
  --debug-port      Specify a port to enable server-side debugging. The
                    server will be paused before any tests run, waiting
                    for incoming connections from debugger clients.
  --mobile-server   If running tests in an emulator or on a mobile device,
                    the location where mobile builds connect to the
                    Meteor server. Defaults to your local IP and the
                    port that the Meteor server binds to. Can include a
                    URL scheme (for example,
                    --mobile-server=https://example.com:443).
  --raw-logs        Run without parsing logs from stdout and stderr.
  --settings, -s    Set optional data for Meteor.settings on the server

  --ios,            Run tests in an emulator or on a mobile device. All of
  --android,        the tests for client and server will run in addition to
  --ios-device,     mobile-specific tests.
  --android-device
  --test-app-path   Set the directory in which to create a temporary app used
                    for tests. Defaults to the system's temporary directory,
                    usually /tmp.
  --verbose         Print all output from builds logs.

>>> self-test
Run tests of the 'meteor' tool.
Usage: meteor self-test [pattern] [--list] [--file pattern] [--changed]
                        [--slow] [--force-online] [--history n]
                        [--browserstack]

Runs internal tests. Exits with status 0 on success.

If 'pattern' is provided, it should be a regular expression. Only
tests that match the regular expression will be run.

Use --list to list the tests that would be run according to the other
options, without running them.

Pass --file to run only tests in files that match the regular expression.

Pass --changed to run only tests that have changed since they last
passed. This uses a really rough heuristic: A test has changed iff
there has been any change to the file in the 'selftests' subdirectory
that defines it. State for this is tracked in ~/.meteortest.

Some tests are really slow. Test flagged as slow won't be run unless
you pass --slow. Remember to do this from time to time!

Normally, this command detects whether you are offline and skips tests that
require network access automatically. If you want to try to run them anyway,
pass --force-online.

Use --history to change the number of lines of program output that are
shown on test failure. The default is 10.

Pass --browserstack to enable client side tests using BrowserStack.
--browserstack requires s3cmd credentials.



>>> open-ide
Open mobile build project in associated IDE.
Usage: meteor open-ide [ios]

Open mobile build project in associated IDE.


>>> admin
Administrative commands.
Usage: meteor admin <command> [args]
       meteor help admin <command>

Rarely used commands for administering official Meteor services.

Commands:
{{commands}}

See 'meteor help admin <command>' for details on an admin command.

>>> admin make-bootstrap-tarballs
Makes bootstrap tarballs.
Usage: meteor admin make-bootstrap-tarballs release@version /tmp/tarballdir

For internal use only.


>>> dummy
Dummy command used for automated testing.
Usage: meteor dummy [options]

Dummy command used for automated testing.

Options:
  --ething, -e  A required string option.
  --port, -p   A numeric option with a short alias.
  --changed    A boolean option.


>>> cordova
Run cordova commands.
Usage: meteor cordova <command>


>>> list-sites
List sites for which you are authorized.
Usage: meteor list-sites

List the sites that you have deployed with 'meteor deploy', and sites
for which other users have authorized you with the 'meteor authorized'
command.


>>> publish-release
Publish a new meteor release to the package server.

Usage: meteor publish-release <path to json config> [--create-track]

Publishes a new release to the package server, as determined by the json
configuration file, which must have the following keys:
  track: the release track to which you are publishing (ex: METEOR)
  version: the version of this release
  recommended: is this a recommended release? (see below)
  description: a brief description of the release
  patchFrom: (Optional) releases from which this is a patch (array of strings)
  tool: <package name>@<version> of the meteor tool that this release specifies
  packages: object of <package name> to <version> for specified package versions

Set the recommended flag to true for recommended releases (ex: METEOR@0.90)
and false for release candidates, experimental releases, etc. You must publish
all package versions to the package server before you can specify them in a
release.

Use the patchFrom flag to submit a patch release. This will automatically
unrecommend the releases specified by the patchFrom flag.

Use the --create-track to publish a new release track.

Options:
  --create-track  publish a new release track.


>>> publish
Publish a new version of a package to the package server.

Usage: meteor publish [--create]
       meteor publish --update

Publishes a new version of a local package to the package server. Must be run
from the directory containing the package. Reads the package.js file for version
information, builds the package and sends both the package source and the built
version of the package to the package server.

This will create at most one build of the package. If the package has an
OS-dependent binary component, publishing will only register metadata about the
package. To actually publish the package builds, use `meteor admin get-machine`
and `meteor publish-for-arch`. Packages with no published builds cannot be added
to applications.

This will mark you as the only maintainer of the package. You can use
'meteor admin maintainers' to change package maintainers. For more information
about admin commands, run 'meteor help admin'.

Change the metadata for a given version of a package by running with the
--update flag. That will set the git url, version summary, longform description
and documentation in the database to their new values. You can use 'meteor show'
to preview the results.

Pass --create to create a new package.

Options:
  --create   publish a new package
  --update   changed metadata of a previously published version
  --allow-incompatible-update   Allow packages in your project to be upgraded or
             downgraded to versions that are potentially incompatible with the
             current versions, if required to satisfy all package version
             constraints.
  --no-lint  don't run linters on the published package and its local
             dependencies before publishing


>>> publish-for-arch
Builds an already-published package for a new platform.

Usage: meteor publish-for-arch packageName@version

When you publish a package with 'meteor publish' for a package which has
platform-specific components (eg, npm modules with native code), the package
will only be usable on machines of the same architecture that you are currently
on. To make your package's version usable on other architectures, you can use
the publish-for-arch command.  (The architectures currently supported by Meteor
are 32-bit Linux, 64-bit Linux, and 64-bit OS X; the 'meteor deploy' servers use
64-bit Linux.)

On a machine of the appropriate architecture, install Meteor and run
  $ meteor publish-for-arch packageName@version

You don't need to have a copy of your package's source to do this: Meteor will
automatically download your package's source and dependencies from the package
server.


>>> rebuild
Rebuild local packages.
Usage: meteor rebuild [<package name>...]

Rebuild specified local packages. Deletes the package's build directory
and rebuilds the package from scratch. Packages are specified by name.

If you pass no arguments, this will rebuild all local packages.
That includes packages found through the
PACKAGE_DIRS environment variable, local packages in the current
application, and, if running Meteor from a checkout, the packages in
the checkout. It doesn't include any packages for which we don't have
the source.

You should never need to use this command. It is intended for use while
debugging the Meteor packaging tools themselves.


>>> search
Search through the package server database.
Usage: meteor search <regex> [--maintainer <username>] [--show-all]

Searches through the Meteor package and release database for items whose names
match the regular expression. You can use the --maintainer option to filter for
items maintained by a particular developer.

By default, this will not show packages that have no official versions
(for example, those that have only prereleases). It will also hide packages
that, due to migration issues, are known to be incompatible with Meteor 0.9.0
and later. You can use the --show-all option to see hidden packages.

Options:
  --maintainer    filter by authorized maintainer
  --show-all      show all matches, even prereleases
  --ejson         show more detailed output in EJSON format


>>> show
Show detailed information about a release or package.
Usage: meteor show <name> [--show-all] [--ejson]
       meteor show <name@version> [--ejson]
       meteor show [--ejson]

Show detailed information on a specific package or release, including
a list of available versions. This works on packages built locally from source,
as well as remote packages stored on the server.  For version-specific information,
such as the list of exports, Meteor will use the local version, if one is available,
or the latest official version.

Use <name>@<version> to get more information about a specific version of a
package or release. Use '<name>@local' to see information from a
local version. Running from a package source directory with no arguments will
show information for that package version.

By default, Meteor will not show more than five versions, and will not
show experimental release versions. Meteor will also hide packages that
are known to not be compatible with  Meteor 0.9.0 and later. Running with the
--show-all option will show everything.

Options:
  --ejson         show more detailed output in EJSON format
  --show-all      show hidden versions of packages and releases


>>> admin maintainers
View or change package maintainers.
Usage: meteor admin maintainers <package name> [--list]
       meteor admin maintainers <package name> --add <username>
       meteor admin maintainers <package name> --remove <username>

Without options (or with --list), list the users and organizations that are
maintainers for a particular package.

With --add, add an authorized maintainer to a package. Use this to give your
collaborators the ability to work with your packages.

With --remove, remove an authorized maintainer from a package. You cannot remove
yourself if you are the last maintainer on a package.

You can only add or remove one maintainer at a time.

Options:
  --add         add an authorized maintainer
  --remove      remove an authorized maintainer
  --list        list authorized maintainers (the default)


>>> admin recommend-release
Recommend a previously published release.
Usage: meteor admin recommend-release
         <release track>@<release version> [--unrecommend]

Recommend a version of a meteor release. Users can be upgraded to recommended
releases automatically when they run meteor update. Users will never be updated
to unrecommended releases unless they explicitly specify that release with a
--release argument.

Use unrecommended releases for release candidates, one-of experiments, etc. Use
recommended releases for official supported releases.

Options:
  --unrecommend         unrecommend a previously recommended release


>>> admin change-homepage
Change the homepage url of a package.
Usage: meteor admin change-homepage <package name> <new url>

Change the homepage containing package information.


>>> admin set-unmigrated
Set the package as unmigrated.
Usage: meteor admin set-unmigrated <package name> [--success]
       meteor admin set-unmigrated <package name>@<version> [--success]

Set a version of a package, as unmigrated: make it invisible in search and show,
without a special option. (You should use this to hide packages that have been
renamed in the aftermath of the 0.9.0 migration.) This will not stop the users
from adding the package to their app.

If no version is passed in, all versions will be set. Use the --success option
to mark the package version as successfully migrated, making it show up again.

Options:
  --success         mark the package as successfully migrated.


>>> admin set-banners
Set banners on published releases.
Usage: meteor admin set-banners <path to banner configuration>

Set the banners on previously published releases. Banners notify the user
when there is a new release available or a patch release has been published.

>>> admin list-organizations
List the organizations of which you are a member.
Usage: meteor list-organizations

List the organizations of which you are a member.

>>> admin members
View or change the members of an organization.
Usage: meteor admin members <organization name> [--list]
       meteor admin members <organization name> --add <username>
       meteor admin members <organization name> --remove <username>

Without options, list the members of an organization. With --add or --remove,
add or remove a member of an organization.

Options:
  --add         add a member to the organization
  --remove      remove a member from the organization
  --list        list members of the organization (the default)

>>> admin set-latest-readme
Set the readme on the latest version of a core meteor package.
Usage: meteor admin set-latest-core-readme name --commit commit
       meteor admin set-latest-core-readme name --tag tag

Set the readme field on the latest published version of a core package to the
readme at a given git commit, or the readme at a given git tag.

>>> admin get-machine
Open an ssh shell to a machine in the meteor build farm.
Usage: meteor admin get-machine <arch> [--json] [--verbose] [--minutes min]

Asks the meteor build farm for a build server and opens a secure shell to it.

Valid machine architectures are:
  os.osx.x86_64
  os.linux.x86_64
  os.linux.x86_32
  os.windows.x86_32

Options:
  --json       return information in JSON form instead of opening a shell
  --minutes    specify the length of the reservation
  --verbose    print all output from commands