emigrate up
The up
command is used to either list or run all pending migrations, i.e. migrations that haven’t been run yet.
Emigrate takes all migration files in the given directory and compares them to the migration history so that it knows which migrations are pending.
It then sorts the pending migrations by filename in ascending order and runs them one by one.
If any of the migrations fail, the command will be aborted and the rest of the migrations will not be run.
Usage
Options
-h
, --help
Show command help and exit
--dry
List the pending migrations that would be run without actually running them
-l, --limit <count>
type: number
Limit the number of migrations to run. Can be combined with --dry
which will show “pending” for the migrations that would be run if not in dry-run mode,
and “skipped” for the migrations that also haven’t been run but won’t because of the set limit.
-d
, --directory <path>
The directory where the migration files are located. The given path should be absolute or relative to the current working directory.
-f
, --from <name/path>
The name of the migration to start from. This can be used to run only a subset of the pending migrations.
The given migration need to exist and is compared in lexicographical order with all migrations, the migration with the same name and those lexicographically after it will be migrated. It’s okay to use an already executed migration as the “from” migration, it won’t be executed again.
The reason for why the given migration name must exist and cannot be just a prefix is to avoid accidentally running migrations that you didn’t intend to run.
The given name can also be a relative path to a migration file, which makes it easier to use with terminals that support tab completion
or when copying the output from Emigrate and using it directly as the value of the --from
option.
Relative paths are resolved relative to the current working directory.
Can be combined with --dry
which will show “pending” for the migrations that would be run if not in dry-run mode,
and “skipped” for the migrations that also haven’t been run but won’t because of the set “from”.
-t
, --to <name/path>
The name of the migration to end at. This can be used to run only a subset of the pending migrations.
The given migration name need to exist and is compared in lexicographical order with all migrations, the migration with the same name and those lexicographically before it will be migrated. It’s okay to use an already executed migration as the “to” migration, it won’t be executed again.
The reason for why the given migration name must exist and cannot be just a prefix is to avoid accidentally running migrations that you didn’t intend to run.
The given name can also be a relative path to a migration file, which makes it easier to use with terminals that support tab completion
or when copying the output from Emigrate and using it directly as the value of the --to
option.
Relative paths are resolved relative to the current working directory.
Can be combined with --dry
which will show “pending” for the migrations that would be run if not in dry-run mode,
and “skipped” for the migrations that also haven’t been run but won’t because of the set “to”.
-i
, --import <module>
A module to import before running the migrations. This option can be specified multiple times.
Can for instance be used to load environment variables using dotenv with --import dotenv/config
,
or for running migrations in NodeJS written in TypeScript with tsx (--import tsx
), see the TypeScript guide for more information.
-s
, --storage <name>
The storage plugin to use, which is responsible for where to store the migration history.
The name can be either a path to a module or a package name. For package names Emigrate will automatically prefix the given name with these prefixes in order:
@emigrate/storage-
emigrate-storage-
@emigrate/plugin-storage-
@emigrate/
And then try to load the module/package with the given name.
For example, if you want to use the emigrate-storage-somedb
package, you can specify either emigrate-storage-somedb
or just somedb
as the name.
In case you have both a emigrate-storage-somedb
and a somedb
package installed, the emigrate-storage-somedb
package will be used.
-p
, --plugin <name>
The loader plugin(s) to use. Can be specified multiple times to use multiple plugins.
The name can be either a path to a module or a package name. For package names Emigrate will automatically prefix the given name with these prefixes in order:
@emigrate/plugin-
emigrate-plugin-
@emigrate/
And then try to load the module/package with the given name.
For example, if you want to use the emigrate-plugin-someplugin
package, you can specify either emigrate-plugin-someplugin
or just someplugin
as the name.
In case you have both a emigrate-plugin-someplugin
and a someplugin
package installed, the emigrate-plugin-someplugin
package will be used.
-r
, --reporter <name>
type: "pretty" | "json" | string
default: "pretty"
The reporter to use for reporting the migration progress.
The name can be either a path to a module or a package name. For package names Emigrate will automatically prefix the given name with these prefixes in order:
@emigrate/reporter-
emigrate-reporter-
@emigrate/
And then try to load the module/package with the given name.
For example, if you want to use the emigrate-reporter-somereporter
package, you can specify either emigrate-reporter-somereporter
or just somereporter
as the name.
--color
, --no-color
Force enable/disable colored output, option is passed to the reporter which should respect it.
--no-execution
Mark the migrations as executed and successful without actually running them, which is useful if you want to mark migrations as successful after running them manually
--abort-respite
type: number
default: 10
Customize the number of seconds to wait before abandoning a running migration when the process is about to shutdown, for instance when the user presses Ctrl+C
or when the container is being stopped (if running inside a container).