meteor/docs/client/full-api/commandline.html

<template name="commandline">
<div>
{{#markdown}}

<h1 id="commandline">Command line</h1>

<!-- XXX some intro text? -->

<h3 id="meteorhelp">meteor help</h3>

Get help on meteor command line usage. Running `meteor help` by
itself will list the common meteor
commands. Running <code>meteor help <i>command</i></code> will print
detailed help about the command.


<h3 id="meteorrun">meteor run</h3>

Run a meteor development server in the current project. Searches
upward from the current directory for the root directory of a Meteor
project. Whenever you change any of the application's source files, the
changes are automatically detected and applied to the running
application.

You can use the application by pointing your web browser at
<a href="http://localhost:3000">localhost:3000</a>. No internet connection is
required.

This is the default command. Simply running `meteor` is the
same as `meteor run`.

To pass additional options to Node.js use the `NODE_OPTIONS` environment variable.
For example: `NODE_OPTIONS='--debug'` or `NODE_OPTIONS='--debug-brk'`

Run `meteor help run` to see the full list of options.


<h3 id="meteorcreate">meteor create <i>name</i></h3>

Create a new Meteor project. By default, makes a subdirectory named *name*
and copies in the template app. You can pass an absolute or relative
path.

You can use the --package option, to create a new package. If used in an
existing app, this command will create a package in the packages
directory.

<h3 id="meteordeploy">meteor deploy <i>site</i></h3>

Deploy 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 need to make sure the DNS for that domain is configured to
point at `origin.meteor.com`.


The first time you deploy an app you'll be prompted for an email address &mdash;
follow the link in your email to finish setting up your account.


Once you have your account you can log in and log out from the command line,
check your username with `meteor whoami`, and run `meteor authorized` to give
other Meteor developers permissions to deploy your app and access its database
and logs.


You can deploy in debug mode by passing `--debug`. This
will leave your source code readable by your favorite in-browser
debugger, just like it is in local development mode.



To delete an application you've deployed, specify
the `--delete` option along with the site.



{{#warning}}
If you use a domain name other than `meteor.com`
you must ensure that the name resolves
to `origin.meteor.com`.  If you want a top-level
domain like myapp.com, you'll need a DNS A record, matching the IP
address of origin.meteor.com.
{{/warning}}



You can add information specific to a particular deployment of your application
by using the `--settings` option.  The argument to `--settings` is a file
containing any JSON string.  The object in your settings file will appear on the
server side of your application in [`Meteor.settings`](#meteor_settings).

Settings are persistent.  When you redeploy your app, the old value will be
preserved unless you explicitly pass new settings using the `--settings` option.
To unset `Meteor.settings`, pass an empty settings file.

<h3 id="meteorlogs">meteor logs <i>site</i></h3>

Retrieves the server logs for the named Meteor application.


Meteor redirects the output of `console.log()` in your
server code into a logging server.  `meteor logs`
displays those logs.  In client code, the output
of `console.log()` is available in your web browser's
inspector, just like any other client-side JavaScript.


<h3 id="meteorupdate">meteor update</h3>

Attempts to bring you to the latest version of Meteor, and then to upgrade your
packages to their latest versions. By default, update will not break
compatibility.

For example, let's say packages A and B both depend on version 1.1.0 of package
X. If a new version of A depends on X@2.0.0, but there is no new version of
package B, running `meteor update` will not update A, because doing so will
break package B.

You can pass in the flag `--packages-only` to update only the packages, and not
the release itself. Similarly, you can pass in names of packages
(`meteor update foo:kittens baz:cats`) to only update specific packages.

Every project is pinned to a specific release of Meteor. You can temporarily try
using your package with another release by passing the `--release` option to any
command; `meteor update` changes the pinned release.

Sometimes, Meteor will ask you to run `meteor update --patch`. Patch releases
are special releases that contain only very minor change (usually crucial bug
fixes) from previous releases. We highly recommend that you always run `update
--patch` when prompted.

You may also pass the `--release` flag to act as an override to update to a
specific release. This is an override: if it cannot find compatible versions of
packages, it will log a warning, but perform the update anyway. This will only
change your package versions if nessesary.


<h3 id="meteoradd">meteor add <i>package</i></h3>

Add packages to your Meteor project. By convention, names of community packages
include the name of the maintainer. For example: `meteor add iron:router`. You
can add multiple packages with one command

Optionally, adds version constraints. 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: for example, `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` again
without specifying a version. For example above, to stop using version `1.1.0`
exactly, run `meteor add package`.


<h3 id="meteorremove">meteor remove <i>package</i></h3>

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

This removes the package entirely. To continue using the package,
but remove its version constraint, use [`meteor add`](#meteoradd).

Meteor does not downgrade transitive dependencies unless it's necessary. This
means that if running `meteor add A` upgrades A's parent package X to a new
version, your project will continue to use X at the new version even after you
run `meteor remove A`.


<h3 id="meteorlist">meteor list</h3>

Lists all the packages that you have added to your project. For each package,
lists the version that you are using. Lets you know if a newer version of that
package is available.

<h3 id="meteoraddplatform">meteor add-platform <i>platform</i></h3>

Adds platforms to your Meteor project. You can add multiple
platforms with one command. Once a platform has been added, you
can use 'meteor run <i>platform</i>' to run on the platform, and 'meteor build'
to build the Meteor project for every added platform.


<h3 id="meteorremoveplatform">meteor remove-platform <i>platform</i></h3>

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


<h3 id="meteorlistplatforms">meteor list-platforms</h3>

Lists all of the platforms that have been explicitly added to your project.


<h3 id="meteormongo">meteor mongo</h3>

Open a MongoDB shell on your local development database, so that you
can view or manipulate it directly.

{{#warning}}
For now, you must already have your application running locally
with `meteor run`. This will be easier in the future.
{{/warning}}


<h3 id="meteorreset">meteor reset</h3>

Reset the current project to a fresh state. Removes the local
mongo database.

{{#warning}}
This deletes your data! Make sure you do not have any information you
care about in your local mongo database by running `meteor
mongo`. From the mongo shell, use `show collections`
and <code>db.<i>collection</i>.find()</code> to inspect your data.
{{/warning}}

{{#warning}}
For now, you can not run this while a development server is
running. Quit all running meteor applications before running this.
{{/warning}}


<h3 id="meteorbuild">meteor build</h3>

Package this project up for deployment. The output is a directory with several
build artifacts:

<ul><li>a tarball that includes everything necessary to run the application server
  (see `README` in the tarball for details)</li>
<li>an unassigned `apk` bundle and a project source if Android is targetted as a
  mobile platform</li>
<li>a directory with an Xcode project source if iOS is targetted as a mobile
  platform</li></ul>

You can use the application server bundle to host a Meteor application on your
own server, instead of deploying to Meteor's servers.  You will have to deal
with logging, monitoring, backups, load-balancing, etc, all of which we handle
for you if you use `meteor deploy`.

Unassigned `apk` bundle and the outputted Xcode project can be used to deploy
your mobile apps to Android Play Store and Apple App Store.

By default, your application is bundled for your current architecture.
This may cause difficulties if your app contains binary code due to,
for example, npm packages. You can try to override that behavior
with the --architecture flag.


<h3 id="meteorsearch">meteor search</h3>

Searches for Meteor packages and releases, whose names contain the specified
regular expression.


<h3 id="meteorshow">meteor show</h3>

Shows more information about a specific package or release: name, summary, the
usernames of its maintainers, and, if specified, its homepage and git URL.


<h3 id="meteorpublish">meteor publish</h3>

Publishes your package. To publish, you must cd into the package directory, log
in with your Meteor Developer Account and run `meteor publish`. By convention,
published package names must begin with the maintainer's Meteor Development
Accounts username and a colon, like so: `iron:router`.

To publish a package for the first time, use `meteor publish --create`.

Sometimes packages may contain binary code specific to an architecture (for
example, they may use an npm package). In that case, running publish will only
upload the build to the architecture that you were using to publish it. You can
use `publish-for-arch` to upload a build to a different architecture from a
different machine.


<h3 id="meteorpublishforarch">meteor publish-for-arch</h3>

Publishes a build of an existing package version from a different architecture.

Some packages contain code specific to an architecture. Running `publish` by
itself, will upload the build to the architecture that you were using to
publish. You need to run `publish-for-arch` from a different architecture to
upload a different build.

For example, let's say you published name:cool-binary-blob from a Mac. If you
want people to be able to use cool-binary-blob from Linux, you should log into a
Linux machine and then run
`meteor publish-for-arch name:cool-binary-blob@version`.  It will notice that you
are on a linux machine, and that there is no Linux-compatible build for your package
and publish one.

Currently, the supported architectures for Meteor are 32-bit Linux, 64-bit Linux
and Mac OS. The servers for `meteor deploy` run 64-bit Linux.


<h3 id="meteorpublishrelease">meteor publish-release</h3>

Publishes a release of Meteor. Takes in a json configuration file.

Meteor releases are divided into tracks. While only MDG members can publish to
the default Meteor track, anyone can create a track of their own and publish to
it. Running `meteor update` without specifying the `--release` option will not
cause the user to switch tracks.

To publish to a release track for the first time, use the `create-track` flag.

The JSON configuration file must contain the name of the release track
(`track`), the release version (`version`), various metadata, the packages
specified by the release as mapped to versions (`packages`), and the package &
version of the Meteor command-line tool (`tool`). Note that this means that
forks of the meteor tool can be published as packages and people can use them by
switching to a corresponding release. For more information, run
`meteor help publish-release`.


<h3 id="meteortestpackages">meteor test-packages</h3>

Test Meteor packages, either by name, or by directory. Not specifying an
argument will run tests for all local packages. The results are displayed in an
app that runs at `localhost:3000` by default. If you need to, you can pass the
`--settings` and `--port` arguments.


<h3 id="meteoradmin">meteor admin</h3>

Catch-all for miscellaneous commands that require authorization to use.

Some example uses of `meteor admin` include adding and removing package
maintainers and setting a homepage for a package. It also includes
various help functions for managing a Meteor release.


{{/markdown}}
</div>
</template>