Migration component that can be used by all applications build with LoopBack 4 to manage migration tasks such as database updates.
It provides a common interface to implement custom migration scripts and automatically handles the versioning of the database and the execution of the scripts based on the application version compared to the database version.
Some dependencies need to be installed as peer dependencies
@loopback/boot
@loopback/context
@loopback/core
@loopback/repositoryand the application needs to have the RepositoryMixin applied and to automatically discover the
application version and the migration scripts the BootMixin is required although there is the option
of manual configuration.
class MyApplication extends BootMixin(RepositoryMixin(Application)) {}npm install loopback4-migrationThis will add the required model, repository and further artifacts to the application. By default,
the module will use the existing data source of the application to create and keep track of the
applied migrations. It will also automatically discover the version of the application based on the
package.json file. The data source and the version of application can also be manually configured,
see Configuration.
import { MigrationComponent } from "loopback4-migration";
export class MyApplication extends BootMixin(
ServiceMixin(RepositoryMixin(RestApplication))
) {
constructor(options?: ApplicationConfig) {
super(options);
// ...
// Bind migration component related elements
this.component(MigrationComponent);
// ...
}
}The custom migration scripts need to implement the MigrationScript interface. The version and the
up() method to handle database upgrades always need to be specified. Optionally, a scriptName and
a description can be set. In addition, if required and technically possible the down() method can
be implemented which will be used to handle downgrades of the database.
Note: downgrading the database to an earlier version might not be possible in all cases and should be considered as an edge case. Sometimes it is just impossible to revert the upgrade logic or in other cases it might not even be required because the upgrade changes are backwards compatible. In any case, it is recommended to create a database backup before updating the database.
Migration scripts added to src/migrations with the file naming convention <scriptName>.migration.ts
are automatically discovered and registered when the application is booted.
It is also possible to manually add migration scripts from different locations
or change the default directory and naming convention, see Configuration.
Another option is to use the @migrationScript decorator to add the binding tag to the migration script class and
bind it to the application.
The decorator also allows to configure the scope
and add additional tags.
Note: Each migration script needs to have a unique class name else it will be discarded as a duplicate.
export interface MigrationScript {
version: string;
scriptName?: string;
description?: string;
up(): ValueOrPromise<any>;
down?(): ValueOrPromise<any>;
}This is an example of a migration script which adds the fullName property to all existing users
without the property.
It utilizes Dependency Injection to retrieve the required dependencies such as repositories.
Note: The @migrationScript decorator would not be required here since the script follows
the naming convention and would be automatically discovered. This is just to show how the decorator
would be used.
src/migrations/1.0.1.migration.ts
import { repository } from "@loopback/repository";
import { MigrationScript, migrationScript } from "loopback4-migration";
import { UserRepository } from "../repositories";
@migrationScript()
export class AddUserFullName implements MigrationScript {
version = "1.0.1";
scriptName = AddUserFullName.name;
description = "add full name to users by combining first and last name";
constructor(
@repository(UserRepository)
private userRepository: UserRepository
) {}
async up(): Promise<void> {
// retrieve all users without fullName property
const users = await this.userRepository.find({
where: { fullName: { exists: false } }
});
// add fullName property to each user
const updateUsers = users.map(user =>
this.userRepository.updateById(user.id, {
fullName: `${user.firstName} ${user.lastName}`
})
);
await Promise.all(updateUsers);
}
async down(): Promise<void> {
// remove fullName property from all users
await this.userRepository.updateAll(<any>{
$unset: { fullName: 0 }
});
}
}The component can be configured in application.ts to overwrite the default values.
appVersion- The application version retrieved frompackage.jsoncan either be overwritten with this property or by setting theAPPLICATION_VERSIONenvironment variable. Note that the module currently only supports Semantic Versioning.dataSourceName- The name of the data source which should be used to track the applied migrations. This is mostly relevant if the application uses more than one data source.modelName- The name of the model which will be used as table or collection name to store the applied migrations.migrationScripts- An array of migration script classes that implement theMigrationScriptinterface. Setting the scripts manually is usually not required since they are automatically discovered and bound to the application. Duplicate scripts will be removed and not bound to the application.
import { MigrationBindings } from "loopback4-migration";
import { MongodbDataSource } from "./datasources";
import { MigrationScript101, MigrationScript102, MigrationScript103 } from "./anyfolder";
export class MyApplication extends BootMixin(
ServiceMixin(RepositoryMixin(RestApplication))
) {
constructor(options?: ApplicationConfig) {
super(options);
// ...
// Configure migration component
this.bind(MigrationBindings.CONFIG).to({
appVersion: "1.0.0",
dataSourceName: MongodbDataSource.dataSourceName,
modelName: "AnyName",
migrationScripts: [MigrationScript101, MigrationScript102, MigrationScript103]
});
// ...
}
}It is also possible to update the default directory and file extension by changing the bootOptions
of the application.
this.bootOptions = {
migrations: {
dirs: ["anyfolder"],
extensions: [".any.extension"],
nested: true
}
};To enable debug logs set the DEBUG environment variable to loopback:migration:*, see
Setting debug strings for further details.
This project is licensed under the MIT license. See the LICENSE file for more info.