mirror of
https://github.com/meteor/meteor.git
synced 2026-05-02 03:01:46 -04:00
e8dbe6c27d
This commit adds the "--platforms" flag to meteor build command. This allows the user to specify which platforms he want to build and build it only. For example, if we pass only android to it, we will build only android and web.cordova. Related to issue #63 (https://github.com/meteor/meteor-feature-requests/issues/63)
1102 lines
46 KiB
Plaintext
1102 lines
46 KiB
Plaintext
>>>
|
|
(the first line of each entry is the summary for autogenerated command lists)
|
|
Usage: meteor [--release <release>] [--help] <built-in command> [args]
|
|
meteor help <built-in command>
|
|
meteor [--version] [--arch]
|
|
meteor [run | test | test-packages] --inspect[-brk][=<port>]
|
|
meteor <node | npm | other> [args]
|
|
|
|
|
|
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.
|
|
|
|
Built-in Commands:
|
|
{{commands}}
|
|
|
|
See 'meteor help <built-in command>' for details on a command.
|
|
|
|
Passing '--inspect' or '--inspect-brk' to 'meteor run', 'meteor test', or
|
|
'meteor test-packages' will enable debugging of the server process.
|
|
|
|
Other Commands:
|
|
|
|
Meteor also bundles 'node' and 'npm' by default. If you use the
|
|
commands 'meteor node' or 'meteor npm', you will be running
|
|
the same versions of 'node' and 'npm' that Meteor uses internally.
|
|
|
|
Other commands can be installed in the same directory as 'node' and
|
|
'npm' and used in all apps using the same version of Meteor. The
|
|
easiest way to install such commands is to add a global npm package
|
|
('yarn', 'jsdoc', etc.) that provides the command:
|
|
|
|
meteor npm install --global <package name>
|
|
|
|
Any executable program(s) added by this command can be invoked just
|
|
like 'meteor node' or 'meteor npm' (for example, 'meteor yarn'):
|
|
|
|
meteor <other command> [args]
|
|
|
|
Note that you may need to reinstall these commands after updating to
|
|
a different version of Meteor.
|
|
|
|
|
|
>>> 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.
|
|
--inspect[-brk][=<port>]
|
|
Enable server-side debugging via debugging clients like
|
|
the Node.js command-line debugger, Chrome DevTools, or
|
|
Visual Studio Code. With --inspect-brk, the server will
|
|
be paused at startup, waiting for clients to attach to
|
|
the process on the specified port (default: 9229).
|
|
--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).
|
|
--cordova-server-port
|
|
Local port where Cordova will serve the content. It's
|
|
important when multiple Cordova apps are build from the same
|
|
Meteor app source code as by default the port is generated
|
|
using the id inside .meteor/.id file.
|
|
--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.
|
|
--extra-packages Run with additional packages (comma separated, for example:
|
|
--extra-packages "package-name1, package-name2@1.2.3")
|
|
--exclude-archs Don't create bundles for certain web architectures
|
|
(comma separated, for example:
|
|
--exclude-archs "web.browser.legacy, web.cordova")
|
|
|
|
>>> debug
|
|
Run the project with server-side debugging enabled.
|
|
|
|
Usage: meteor debug [run options] # deprecated
|
|
meteor --inspect[-brk][=<port>] [run | test | test-packages] [options]
|
|
|
|
Enable server-side debugging via debugging clients like the Node.js
|
|
command-line debugger, Chrome DevTools, or Visual Studio Code. With
|
|
--inspect-brk, the server will be paused at startup, waiting for clients
|
|
to attach to the process on the specified port (default: 9229).
|
|
|
|
The 'meteor debug' command is deprecated in favor of 'meteor --inspect-brk'.
|
|
|
|
The syntax of the --inspect and --inspect-brk flags is the same as the
|
|
corresponding Node.js options:
|
|
https://nodejs.org/en/docs/inspector/#command-line-options
|
|
|
|
Two notable differences from the Node.js behavior:
|
|
|
|
* The --inspect[-brk] flags affect the server process spawned by the build
|
|
process, rather than affecting the build process itself.
|
|
|
|
* The --inspect-brk flag causes the server process to pause just after
|
|
server code has loaded but before it begins to execute, giving the
|
|
developer a chance to set breakpoints in server code.
|
|
|
|
An alternative way to set breakpoints is to use the `debugger` keyword:
|
|
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger
|
|
|
|
Options:
|
|
--inspect
|
|
--inspect=<port>
|
|
--inspect-brk
|
|
--inspect-brk=<port>
|
|
Enable server-side debugging via debugging clients like
|
|
the Node.js command-line debugger, Chrome DevTools, or
|
|
Visual Studio Code. With --inspect-brk, the server will
|
|
be paused at startup, waiting for clients to attach to
|
|
the process on the specified port (default: 9229).
|
|
|
|
|
|
>>> create
|
|
Create a new project.
|
|
Usage: meteor create [--release <release>] [--bare|--minimal|--full|--react|--vue|--apollo|--svelte|--blaze] <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. Use the --bare option to create an empty app, or the --minimal option
|
|
to create an empty app with as few Meteor packages as possible. To scaffold a
|
|
more complete app, use the --full option. To create a basic react-based app,
|
|
pass the --react option.
|
|
|
|
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.
|
|
--bare Create an empty app.
|
|
--minimal Create an app with as few Meteor packages as possible.
|
|
--full Create a fully scaffolded app.
|
|
--react Create a basic react-based app, same as default.
|
|
--vue Create a basic vue-based app.
|
|
--apollo Create a basic apollo-based app.
|
|
--svelte Create a basic svelte-based app.
|
|
--typescript Create a basic Typescript React-based app.
|
|
--blaze Create a basic blaze-based app.
|
|
|
|
|
|
>>> 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 ...]
|
|
meteor update --all-packages
|
|
|
|
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').
|
|
|
|
Passing --all-packages will update all packages, including indirect
|
|
dependencies, to their latest compatible versions. This is similar to passing
|
|
the names of all project packages to the 'meteor update' command. Note that
|
|
updated packages must meet the constraints imposed by other packages used by
|
|
the project. This means that some packages, while updated, might still not be
|
|
updated to their most recent version.
|
|
|
|
To get more information about why a package is kept from upgrading, run the
|
|
following:
|
|
|
|
meteor add <package>@<target-version>
|
|
|
|
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.
|
|
--all-packages Update all packages including indirect dependencies.
|
|
|
|
|
|
>>> 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
|
|
meteor list --tree [--weak]
|
|
meteor list --json [--weak] [--details]
|
|
|
|
Lists the packages that you have explicitly added to your project.
|
|
Transitive dependencies are not listed unless you use the --tree option,
|
|
which outputs a tree showing how packages are referenced.
|
|
|
|
Use the --json option to output the tree in JSON format.
|
|
|
|
Options:
|
|
--weak Show weakly referenced dependencies in the tree.
|
|
--details Adds more package details to the JSON output.
|
|
|
|
>>> 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.
|
|
|
|
>>> ensure-cordova-dependencies
|
|
Ensure that Cordova dependencies are installed.
|
|
Usage: meteor ensure-cordova-dependencies
|
|
|
|
Check if the dependencies are installed, otherwise install them.
|
|
|
|
>>> 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, os.linux.x86_32,
|
|
os.windows.x86_32, and os.windows.x86_64. Note: This
|
|
option selects the architecture of the binary-dependent
|
|
Atmosphere packages you would like bundled into your
|
|
application, when those packages were specifically
|
|
published for multiple architectures (i.e. with meteor
|
|
publish-for-arch). If your project doesn't use any
|
|
Atmosphere packages that have binary dependencies,
|
|
--architecture has no effect.
|
|
--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.
|
|
--platforms Builds only the specified platforms (when available).
|
|
|
|
|
|
|
|
>>> 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 local Mongo database
|
|
Usage: meteor mongo [--url]
|
|
|
|
Opens a Mongo shell to view or manipulate collections.
|
|
|
|
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
|
|
|
|
Currently, this feature can only be used when developing locally.
|
|
The opened Mongo shell connects to the current project's local
|
|
development database. The current working directory must be a Meteor
|
|
project directory, and the Meteor application must already be running.
|
|
|
|
>>> 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 Galaxy, Meteor's hosting service.
|
|
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 'meteorapp.com'
|
|
without any additional configuration, for example,
|
|
'myapp.meteorapp.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 / Galaxy docs (http://galaxy-guide.meteor.com/dns.html) 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.
|
|
--deploy-polling-timeout The number of milliseconds to wait for build/deploy
|
|
success or failure after a successful upload of your app's
|
|
minified code; defaults to 15 minutes.
|
|
--no-wait Exits when Meteor has uploaded the app's code instead of
|
|
waiting for the deploy to conclude.
|
|
--cache-build Reuses the build already created if the git commit hash is the
|
|
same
|
|
--free When deploying an app for the first time, you can pass this option
|
|
to deploy your app in the Galaxy's free mode.
|
|
--plan You can change the app plan by providing this argument with one of
|
|
the following values: professional, essentials, or free. Be aware
|
|
that this argument overwrites the --free argument.
|
|
--mongo If this flag is true and it's not provided a mongo url in the settings
|
|
('galaxy.meteor.com'.env.MONGO_URL), when deploying, Galaxy will create
|
|
a database to your app in its shared cluster and will insert the URL in
|
|
your app's settings for you.
|
|
|
|
>>> 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 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
|
|
--remove remove an authorized user or organization
|
|
--transfer transfer the (Galaxy) app to a new user or organization
|
|
--list list authorized users and organizations (the default)
|
|
|
|
|
|
>>> 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, $METEOR_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.
|
|
--inspect[-brk][=<port>]
|
|
Enable server-side debugging via debugging clients like
|
|
the Node.js command-line debugger, Chrome DevTools, or
|
|
Visual Studio Code. With --inspect-brk, the server will
|
|
be paused at startup, waiting for clients to attach to
|
|
the process on the specified port (default: 9229).
|
|
--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).
|
|
--cordova-server-port
|
|
Local port where Cordova will serve the content. It's
|
|
important when multiple Cordova apps are build from the same
|
|
Meteor app source code as by default the port is generated
|
|
using the id inside .meteor/.id file.
|
|
--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.
|
|
--extra-packages Run with additional packages (comma separated, for example:
|
|
--extra-packages "package-name1, package-name2@1.2.3")
|
|
--driver-package Test driver package to use to run tests and display results.
|
|
For example: --driver-package meteortesting:mocha
|
|
|
|
>>> 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 temporary app based on a test driver (specified with
|
|
--driver-package: http://guide.meteor.com/testing.html#driver-packages) which
|
|
handles the task of running tests and displaying the results in the browser.
|
|
|
|
In normal 'meteor 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). These eagerly-loaded test modules can import application
|
|
modules in order to test application logic.
|
|
|
|
In 'meteor test --full-app' mode, your app is loaded as usual, then hidden, so
|
|
that your tests can inspect and interact with the full running application.
|
|
Test files are loaded similarly to 'meteor test' mode, but must be called
|
|
*.app-test[s].* or *.app-spec[s].*.
|
|
|
|
Note: as of Meteor 1.7, you can override the default test loading rules
|
|
described in the previous two paragraphs by including a meteor.testModule
|
|
section in your package.json file:
|
|
|
|
"meteor": {
|
|
"testModule": {
|
|
"client": "client/tests.js",
|
|
"server": "server/tests.js"
|
|
}
|
|
}
|
|
|
|
If your client and server test files are the same, this can be simplified to
|
|
|
|
"meteor": {
|
|
"testModule": "tests.js"
|
|
}
|
|
|
|
When meteor.testModule is defined in package.json, the same test module will
|
|
be loaded whether or not you use the --full-app option. Any tests that need to
|
|
know whether the --full-app option was used may check Meteor.isAppTest, which
|
|
is true when running 'meteor test --full-app'. The module specified by
|
|
meteor.testModule can import other test modules at runtime, so it is still
|
|
possible to distribute test files across your codebase.
|
|
|
|
Once your application starts up in testing mode, 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.
|
|
--inspect[-brk][=<port>]
|
|
Enable server-side debugging via debugging clients like
|
|
the Node.js command-line debugger, Chrome DevTools, or
|
|
Visual Studio Code. With --inspect-brk, the server will
|
|
be paused at startup, waiting for clients to attach to
|
|
the process on the specified port (default: 9229).
|
|
--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).
|
|
--cordova-server-port
|
|
Local port where Cordova will serve the content. It's
|
|
important when multiple Cordova apps are build from the same
|
|
Meteor app source code as by default the port is generated
|
|
using the id inside .meteor/.id file.
|
|
--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.
|
|
--extra-packages Run with additional packages (comma separated, for example:
|
|
--extra-packages "package-name1, package-name2@1.2.3")
|
|
--driver-package Name of the optional test driver package to use to run
|
|
tests and display results. For example:
|
|
--driver-package practicalmeteor:mocha
|
|
--exclude-archs Don't create test bundles for certain web architectures
|
|
(comma separated, for example:
|
|
--exclude-archs "web.browser.legacy, web.cordova")
|
|
|
|
>>> self-test
|
|
Run tests of the 'meteor' tool.
|
|
Usage: meteor self-test [pattern] [--list] [--file pattern] [--changed]
|
|
[--slow] [--force-online] [--history n]
|
|
[--browserstack] [--phantom] [--retries n]
|
|
|
|
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.
|
|
|
|
Pass --phantom to enable client side tests using Phantom.
|
|
|
|
By default, failed tests are retried twice. Use --retries to change
|
|
the number of retries, or disable retries by setting the value to 0.
|
|
|
|
|
|
>>> 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. Lists by region, default is us-east-1.
|
|
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. To see sites in a region other than us-east-1, set the DEPLOY_HOSTNAME
|
|
environment variable. For example,
|
|
`DEPLOY_HOSTNAME=eu-west-1.galaxy-deploy.meteor.com meteor list-sites`
|
|
|
|
|
|
>>> 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. The binary component will be compiled when it is installed into an
|
|
application with `meteor add`. To pre-build a package for a particular platform,
|
|
use the `meteor publish-for-arch` command.
|
|
|
|
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
|
|
METEOR_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.
|
|
|
|
The 'meteor admin get-machine' command has been disabled and the build farm has
|
|
been discontinued. As of Meteor 1.4, packages with binary dependencies are
|
|
automatically compiled when they are installed in an application, assuming the
|
|
target machine has a basic compiler toolchain.
|
|
|
|
To see the requirements for this compilation step, consult the
|
|
platform requirements for 'node-gyp':
|
|
|
|
https://github.com/nodejs/node-gyp
|