meteor/tools/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 <name>' 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 [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.

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.
  --production  Simulate production mode. Minify and bundle CSS and JS files.
  --raw-logs    Run without parsing logs from stdout and stderr.
  --settings    Set optional data for Meteor.settings on the server
  --release     Specify the release of Meteor to use
  --program     The program in the app to run (Advanced)
  --no-server   Don't start the server, only launch the specified mobile builds.


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

Make a subdirectory named <name> and create a new Meteor project
there. If the package option is specified, creates a meteor package,
otherwise creates a meteor app. You can also pass an absolute or relative path.

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.


>>> run-upgrader
Execute a specific upgrader by name. Intended for testing.
Usage: meteor 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] [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.


>>> remove
Remove a package from this project
Usage: meteor remove <package> [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'.


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

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

Also lists the Cordova plugins and platforms used by your mobile
build directly.

>>> bundle
Pack this project up into a tarball
Usage: meteor bundle <output_file.tar.gz>

Package this project up for deployment. The output is a tarball that
includes everything necessary to run the application. See README in
the tarball for details.

Options:
  --debug      bundle in debug mode (don't minify, etc)
  --directory  output a directory (rather than a tarball). If the output
               location exists, it will be recursively deleted first.
  --ios        XXX
  --android    XXX
  --settings   XXX


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

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 minute.

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    set optional data for Meteor.settings
  --star        a star (tarball) to deploy instead of the current Meteor app


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

Retrieves the server logs for the requested site.


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

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

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

With --remove, remove an authorized user 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.

Options:
  --add         add an authorized user
  --remove      remove an authorized user
  --list        list authorized users (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. Alternatively, you can deploy the tests onto the 'meteor
deploy' server by using --deploy. This gives you a public URL that you
can use in conjunction with a service like Browserling or BrowserStack
to try the tests against many different browser versions.

Options:
  --port, -p        Port to listen on (instead of the default 3000). Also
                    uses port N+1 and N+2.
  --deploy          Optionally, specify a domain to deploy to, rather than
                    running locally.
  --production      Simulate production mode. Minify and bundle CSS and JS files.
  --settings        Set optional data for Meteor.settings on the server

  --ios,            Starts an emulator or an app on device with the app running
  --android,        unit tests specific to the mobile build in addition to
  --ios-device,     the regular server and web-app.
  --android-device


>>> self-test
Run tests of the 'meteor' tool.
Usage: meteor self-test [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.

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.


>>> 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:
  --email, -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-CORE)
  version: the version of this release
  recommended: is this a recommended release? (see below)
  description: a brief description of the release
  patchFrom: (Optional) an array of strings specifying releases from which this is a patch
  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-CORE@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]

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 only create one build of the package. If your package has multiple
builds for different OS architectures, it will create a build for this machine's
architecture. To publish a different build for the same version, run
publish-for-arch.

This will mark you as the only maintainer of the package. If you need to change
maintainers and other metadata about this package & package version, take a look
at the admin commands.

Pass --create to create a new package.

Options:
  --create   publish a new package


>>> 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 a specified local packages. Deletes the package's build directory
and rebuilds the package from scratch. Please specify the package 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 <string>
       meteor search --details <package or release name>
       meteor search --mine

Search through the meteor package&release database for names containing the
specified substring.

Use --details to get detailed information on a specific package or release.
Use --details <name>@<version> to get more information on a specific version
of a package or release.

Use --mine to get the list of packages on which you are one of the authorized
maintainers.

Options:
  --details  show detailed information on a specific package or release
  --mine     list packages on which you are the maintainer

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

Without an argument (or with --list), list the users 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> [--unrecomend]

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 repository url of a package.
Usage: meteor admin change-homepage <package name> <new url>

Change the homepage containing package information.


>>> 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.