DEV Community: Rizky Ikbal

Decorator-like function as in typescript on PHP

Rizky Ikbal — Fri, 07 Jun 2024 10:47:57 +0000

When working with PHP, I wanted to modify the behavior of class methods, aiming to achieve a method decorator similar to Typescript's method decorators. I searched for a decorator-like function but couldn't find anything suitable, so I experimented with creating one. In this blog, I will share my findings and demonstrate how to achieve a method decorator-like function in PHP, similar to those in TypeScript.

What is decorator

In TypeScript, a decorator is a special kind of declaration that can be attached to a class, method, accessor, property, or parameter. Decorators provide a way to add both annotations and metadata to the target they are attached to.

This is an example of typescript's method decorator in action:

export function simpleDecorator(): MethodDecorator {
  return function (target: any, propertyKey: string, descriptor: PropertyDescriptor): void {
    const originalMethod = descriptor.value;
    descriptor.value = async function (...args: any[]) {
      try {
        console.log("[Before trigger method] Hello from decorator");
        const result = await originalMethod.apply(this, args);
        console.log("[After trigger method] Hello from decorator");
        return result;
      } catch (err: any) {
        // error handler
        throw err;
      }
    };
  };
}

class ServiceA {
  @simpleDecorator()
  public methodA() {
    console.log("Hello From Method");
  }
}

const serviceA = new ServiceA();
serviceA.methodA();
// Output:
// [Before trigger method] Hello from decorator
// Hello From Method
// [After trigger method] Hello from decorator

Why decorator?

Using decorators offers several benefits that can greatly enhance the efficiency and readability of your code. Here are some key reasons why decorators are useful:

Code Reusability and DRY Principle
- Reusability: Decorators allow you to define reusable pieces of code that can be applied across multiple classes or methods. This eliminates the need to write repetitive logic in multiple places.
- DRY Principle: By abstracting common functionality into decorators, you adhere to the "Don't Repeat Yourself" principle, reducing code duplication and making your codebase cleaner and easier to maintain.
Separation of Concerns, decorators help separate cross-cutting concerns (like logging, authorization, validation, etc.) from the business logic. This keeps your core logic focused and straightforward.
Enhanced Readability and Maintainability
- Readability: Using decorators makes it clear what additional behaviors or metadata are associated with a class or method. This can make the code more readable and self-documenting.
- Maintainability: Since decorators encapsulate specific behaviors, any changes to these behaviors can be made in one place (the decorator itself) rather than scattered throughout the codebase.

My Findings and Experimentations

When i try to achieve this goal i found some solutions that have each advantages that others dont.

Solution One

class SimpleDecorator
{
    private $target;
    public function __construct($target)
    {
        $this->target = $target;
    }

    public function __call($method, $args)
    {
        echo "[Decorator:Before] Hello\n";
        $result = call_user_func_array(array($this->target, $method), $args);
        echo "\n[Decorator:After] Hi\n";
        return $result;
    }
}

class ServiceA
{
    public function methodA()
    {
        echo "Method Triggered";
    }
}

$serviceA = new SimpleDecorator(new ServiceA());
$serviceA->methodA();
// Output:
// [Decorator:Before] Hello
// Method Triggered
// [Decorator:After] Hi

In order to achieve a decorator-like function we need one of php class's magic method which is __call method, this method will be triggered when a method that being called is not defined and bring along the method name and the arguments its sent.

on the example above you can see that our decorator accept a parameter called $target, which is expected to be the class to which the decorator is applied.

on the implementation, we try to call methodA, one of the methods of class ServiceA through decorator SimpleDecorator which doesnt have methodA, this will trigger __call and allowing us to use the informations it sent to call methodA from the target class which is ServiceA.

one of decorator's characteristic is its can be stacked, let's see how we can stack the decorators:

class AnotherSimpleDecorator
{
    private $target;
    public function __construct($target)
    {
        $this->target = $target;
    }

    public function __call($method, $args)
    {
        echo "\n[AnotherDecorator:Before] Hello\n";
        $result = call_user_func_array(array($this->target, $method), $args);
        echo "[AnotherDecorator:After] Hi\n";
        return $result;
    }
}
$serviceA = new AnotherSimpleDecorator(new SimpleDecorator(new ServiceA()));
$serviceA->methodA();
// Output:
// [AnotherDecorator:Before] Hello
// [Decorator:Before] Hello
// Method Triggered
// [Decorator:After] Hi
// [AnotherDecorator:After] Hi

on this example, we stack AnotherSimpleDecorator on top of SimpleDecorator that applied to ServiceA.
When multiple decorators applied, their evaluation is similar to function composition in mathematics.

As such, the following steps are performed when evaluating multiple decorators:

The expressions for each decorator are evaluated top-to-bottom (in this case it's left-to-right).
The results are then called as functions from bottom-to-top (in this case it's left-to-right).

This solution applies the decorator to all methods, but how can we specify which methods it need to be applied by the decorator or customize the decorator's behavior?. Well, we can do that on this solution but its mean you need to apply the same customization to all decorators and it will break the points on Why decorator? section, that's why solution two come to the rescue.

Solution One full code: here

Solution Two

We got the idea from solution one let's make it more advanced.

class BaseDecorator
{
    private $target;
    private $include_methods = [];
    public function __construct($target, array $include_methods = [])
    {
        $this->target = $target;
        $this->include_methods = $include_methods;
        $this->registerMethods();
    }

    private function registerMethods()
    {
        if (!method_exists($this->target, "handler"))
            throw new Exception("Undefined Decorator Handler \n");

        $methods = get_class_methods($this->target);
        foreach ($methods as $method) {
            $include_method = in_array($method, $this->include_methods);
            if ($include_method)
                runkit7_method_rename(get_class($this->target), $method, "__$method");
        }
    }

    public function __call($method, $args)
    {
        if (!method_exists($this->target, "__$method"))
            throw new Exception("Call attempt on undefined method: $method\n");

        $original_method = function () use ($method, $args) {
            return call_user_func_array(array($this->target, "__$method"), $args);
        };

        return call_user_func_array(array($this->target, "handler"), [$original_method]);
    }
}

class SimpleDecorator extends BaseDecorator
{
    public function __construct($target, array $include_methods = [])
    {
        parent::__construct($target, $include_methods);
    }

    public function handler($original_method)
    {
        echo "[Decorator:Before] Hello\n";
        $result = $original_method();
        echo "\n[Decorator:After] Hi\n";
        return $result;
    }
}

now we have BaseDecorator this make us have the power to control decorator's behavior. on the second parameter we add $include_methods as a configurations parameter to handle which method the decorator need to be applied.

Also, we added registerMethods to BaseDecorator, this method serves two purpose:

This method ensures that every decorator has a method called handler, which will serve as decorator's logic, handler method have a paremeter $original_method, representing the original method that the class tryng to call.
This method renames all the methods from the $target class that match the $include_methods config by prefixing them with "__", with the help of runkit7 extension. This ensures that when a method from a class with the applied decorator is called, it will trigger the __call method.

NOTE:
Im using php 7.4 and runkit7-4.0.0a6

let's see SimpleDecorator in action:

class ServiceA extends SimpleDecorator
{
    public function __construct()
    {
        parent::__construct($this, ['methodA']);
    }

    public function methodA()
    {
        echo "MethodA Triggered";
    }

    public function methodB()
    {
        echo "\nMethodB Triggered\n";
    }
}

$serviceA = new ServiceA();
$serviceA->methodA();
// Output:
// [Decorator:Before] Hello
// MethodA Triggered
// [Decorator:After] Hi

$serviceA->methodB();
// Output:
// MethodB Triggered

When try to use SimpleDecorator we only need the decorator to be applied to methodA, hence the output.

Conclusion, Solution two allowing us to have more control at the base level, make our decorators to focus on handling their specific logic and make the decorator declaration much simpler, but it make decorators not stackable.

Solution Two full code: here

Solution Three

Solution three pretty much the same as solution two but it use the same approach in solution one.

trait BaseDecorator
{
    public $__base_target = [
        "class_name" => "",
        "methods" => [],
    ];
    private $target;
    private $handler;
    private array $method_options = [];
    private array $include_methods = [];

    public function construct($target, callable $handler, array $include_methods = [])
    {
        $this->target = $target;
        $this->handler = $handler;
        $this->include_methods = $include_methods;

        $this->setupBaseTarget();
    }

    private function setupBaseTarget()
    {
        $not_settled = empty(@$this->target->__base_target['class_name'] ?? "");
        if ($not_settled) {
            $this->__base_target = [
                "class_name" => get_class($this->target),
                "methods" => get_class_methods($this->target),
            ];
        } else
            $this->__base_target = $this->target->__base_target;
    }

    public function __call($method, $args)
    {
        $base_target_methods = $this->__base_target['methods'];
        if (!in_array($method, $base_target_methods))
            throw new Exception("Call attempt on undefined method: $method\n");

        $original_method = function () use ($method, $args) {
            return call_user_func_array(array($this->target, $method), $args);
        };

        $use_handler = in_array($method, $this->include_methods);
        return $use_handler ? call_user_func($this->handler, $original_method) : $original_method();
    }
}

here is the key different between solution three and two:

handler as parameter not as method.
BaseDecorator as a trait instead of a class, since we gonna use the same approach in solution one, we dont need to rename the method in order to make __call being triggered, so we can exclude registerMethods.
We have setupBaseTarget, this method responsible for initializing or copying $target's info.

when applying multiple decorators for example:

     $serviceA = new DecoratorB(new DecoratorA(new ServiceA()));

DecoratorB's $target is DecoratorA, setupBaseTarget ensuring all decorators that applied have access to the original target class's info which is ServiceA.

let's declare a decorator called SimpleDecorator using BaseDecorator:

class SimpleDecorator
{
    use BaseDecorator;
    public function __construct($target, array $include_methods = [])
    {
        $handler = function ($original_method) {
            echo "[Decorator:Before] Hello\n";
            $result = $original_method();
            echo "[Decorator:After] Hi\n";
            return $result;
        };

        $this->construct($target, $handler, $include_methods);
    }
}

let's use the decarotor:


class ServiceA
{
    public function methodA()
    {
        echo "MethodA Triggered\n";
    }

    public function methodB()
    {
        echo "\nMethodB Triggered\n";
    }
}
$serviceA = new SimpleDecorator(new ServiceA(), ['methodA']);
$serviceA->methodA();
// Output:
// [Decorator:Before] Hello
// MethodA Triggered
// [Decorator:After] Hi

$serviceA->methodB();
// Output:
// MethodB Triggered

Stacked decorators in action:

class AnotherSimpleDecorator
{
    use BaseDecorator;
    public function __construct($target, array $include_methods = [])
    {
        $handler = function ($original_method) {
            echo "[AnotherDecorator:Before] Hello\n";
            $result = $original_method();
            echo "[AnotherDecorator:After] Hi\n";
            return $result;
        };

        $this->construct($target, $handler, $include_methods);
    }
}
$serviceA = new AnotherSimpleDecorator(
    new SimpleDecorator(new ServiceA(), ['methodA']),
    ['methodA']
);
$serviceA->methodA();
// Output:
// [AnotherDecorator:Before] Hello
// [Decorator:Before] Hello
// Method Triggered
// [Decorator:After] Hi
// [AnotherDecorator:After] Hi

Solution Three full code: here

Conclusion, Solution three make decorators stackable but when it come to stacked decorator the declaration become ugly.

with this we cover pretty much all the points on section Why decorator?

That's all I wanted to share. I hope this information helps you in some way.

NOTE:
If you interested in typescript decorator i suggest you check the official documentation here or you can check my other blog: Typescrypt: Make your life easier with decorators

Typescrypt: Make your life easier with decorators

Rizky Ikbal — Fri, 31 May 2024 10:23:55 +0000

What is decorator?

In TypeScript, decorator is a special type of declaration that uses the @ symbol to customize classes and their members, allowing us to add metadata or modify their behavior at runtime.

Brief History

Decorators were initially introduced as an experimental feature in TypeScript 1.5 in July 2015, and using them required enabling a specific compiler option called --experimentalDecorators.

Why decorator?

Using decorators offers several benefits that can greatly enhance the efficiency and readability of your code. Here are some key reasons why decorators are useful:

Code Reusability and DRY Principle
- Reusability: Decorators allow you to define reusable pieces of code that can be applied across multiple classes or methods. This eliminates the need to write repetitive logic in multiple places.
- DRY Principle: By abstracting common functionality into decorators, you adhere to the "Don't Repeat Yourself" principle, reducing code duplication and making your codebase cleaner and easier to maintain.
Separation of Concerns
Decorators help separate cross-cutting concerns (like logging, authorization, validation, etc.) from the business logic. This keeps your core logic focused and straightforward.
Enhanced Readability and Maintainability
- Readability: Using decorators makes it clear what additional behaviors or metadata are associated with a class or method. This can make the code more readable and self-documenting.
- Maintainability: Since decorators encapsulate specific behaviors, any changes to these behaviors can be made in one place (the decorator itself) rather than scattered throughout the codebase.

Getting Started

Make sure TypeScript is installed on your system, or you can install it locally within your specific project.

In this blog, I'll be using TypeScript v5.4.5, the latest version as of May 24, 2024, installed using npm and configured in Visual Studio Code settings.

To install the latest version of TypeScript and the necessary type definitions for Node.js, use the following command:

npm i typescript@latest @types/node -D

Ensure you configure VS Code to use the TypeScript version installed via npm by adding the following line to your .vscode/settings.json file:

{
  "typescript.tsdk": "node_modules/typescript/lib"
}

This setting directs VS Code to use the TypeScript language server from the directory installed by npm.

you must enable the experimentalDecorators compiler option either via command or your tsconfig.json file.

{
  "experimentalDecorators": true
}

Decorator Declaration

The syntax of a decorator is pretty simple, just add the @ operator before the decorator you want to use, then the decorator will be applied to the target:

const simpleDecorator: ClassDecorator = function () {
  console.log("hi I am a decorator");
};

@simpleDecorator
class ClassA {}
// Output:
// hi I am a decorator

Decorator Factory

Decorator factory is a function that returns a decorator. It allows you to pass parameters to a decorator. here is how it look like:

function addProperty<T>(name: string, value: T) {
  return function (target: { new (...arg: any[]) }): void {
    target.prototype[name] = value;
  };
}

@addProperty<boolean>("isNew", true)
class ClassB {}

console.log(ClassB.prototype);
// Output:
// { isNew: true }

Here's a breakdown of a decorator and a decorator factory:

Decorator: A special kind of declaration that can be attached to a class, method, accessor, property, or parameter to modify their behavior or add metadata.
Decorator Factory: A function that returns a decorator, enabling you to customize the decorator with parameters.

Examples

There are various types of decorators in TypeScript, such as class decorators, property decorators, Method Decorator, Accessor Decorator, and parameter decorators. In this guide, we'll focus on method decorators.

Behavior at runtime

as you know decorators are usefull tools that allow us to modify the behavior of classes and their members at runtime. Let's say you have a log decorator with a message parameter, and you want to make sure that the message isn't an empty string. You can accomplish this by add the validation before return the decorator.

function simpleDecorator(message: string): MethodDecorator {
  if (message.length === 0) throw Error("Invalid Argument: Doesnt allowed empty string");

  return function (): void {
    console.log("Method triggered");
  };
}

This will throw an error as soon as you run the codes:

class ServiceA {
  @simpleDecorator("") // Error: Invalid Argument: Doesnt allowed empty string
  public methodA() {}
}

This one is valid:

class ServiceA {
  @simpleDecorator("a")
  public methodA() {}
}

Decorators are stackable

Decorators can be stacked:

const first: MethodDecorator = function () {
  console.log("first");
};
const second: MethodDecorator = function () {
  console.log("second");
};

class ClassA {
  @first
  @second
  methodA() {}
}

// Output:
// second
// first

When multiple decorators apply to a single declaration, their evaluation is similar to function composition in mathematics.

As such, the following steps are performed when evaluating multiple decorators on a single declaration in TypeScript:

The expressions for each decorator are evaluated top-to-bottom.
The results are then called as functions from bottom-to-top.

Class method as decorator factory

You can also use class methods as decorator factories to create more complex and reusable decorators.

Let's say you have a custom logger class that can print messages with a custom prefix and measure the time taken between different pieces of code.

class Logger {
  private performanceTimeLog: {
    timestamp: number;
    // logId: string // You can add custom property here to help you log your messages better
  }[] = [];
  constructor(public readonly instance: string) {}

  public performanceStart = (message: string) => {
    this.performanceTimeLog.push({ timestamp: performance.now() });
    this.log(message);
    return this.performanceTimeLog.length - 1;
  };

  public performanceEnd = (timeStartIndex: number, message: string) => {
    const performanceTime = this.performanceTimeLog[timeStartIndex];
    if (typeof performanceTime === "undefined") throw Error("Define performanceStart first");

    const getTime = (performance.now() - performanceTime.timestamp).toFixed();

    this.printPerformanceMessage(message, getTime);
  };

  private printPerformanceMessage(message: string, time: string) {
    this.log(`${message}, +${time}ms`);
  }

  public log(message: string) {
    process.stdout.write(`[${this.instance}] ${message}\n`);
  }
}

const serviceLogger = new Logger("SERVICE");

const timeStartIndex = serviceLogger.performanceStart("LOG");
serviceLogger.log("Hello there");
serviceLogger.performanceEnd(timeStartIndex, "LOG");
// Output:
// [SERVICE] LOG
// [SERVICE] Hello there
// [SERVICE] LOG, +1ms

Let's add a decorator that measures the time taken by the method it is applied to.

class Logger {
  ...
  ...
  ...
  public decoratorFunctionPerformance({ message }: { message?: string }) {
    return ((self: typeof this) => {
      return function (target: any, propertyKey: string, descriptor: PropertyDescriptor) {
        const usedMessage = message ?? `EXECUTE ${propertyKey}`;
        const original = descriptor.value;
        descriptor.value = async function (...args: any[]) {
          const performanceIndex = self.performanceStart(`START ${usedMessage}`);
          try {
            const result = await original.apply(this, args);
            return result;
          } catch (err: any) {
            // error handler
            throw err;
          } finally {
            self.performanceEnd(performanceIndex, `END ${usedMessage}`);
          }
        };
      };
    })(this);
  }
}

Now we have decoratorFunctionPerformance, which is a class method acting as a decorator factory. The method itself is an immediately-invoked function expression (IIFE), enabling access to the this context (Logger instance). This allows us to access the logger instance within our decorator function.

Inside the decorator, we apply the performance timing function both before and after the original method is executed.

Let's see decoratorFunctionPerformance in action:

const serviceLogger = new Logger("SERVICE");
class ServiceA {
  @serviceLogger.decoratorFunctionPerformance({})
  public async methodA() {
    return new Promise((resolve, reject) => {
      setTimeout(() => {
        resolve(true);
      }, 500);
    });
  }
}
const serviceA = new ServiceA();
serviceA.methodA();
// Output:
// [SERVICE] START EXECUTE methodA
// [SERVICE] END EXECUTE methodA, +503ms

On the example above, we applied decoratorFunctionPerformance to methodA causing it to wait for 500ms before returning the value true. Therefore, the execution time will be at least 500ms.

You can see full code here

That's all I wanted to share. I hope this information helps you in some way.

Get Rid of Migration Files

Rizky Ikbal — Fri, 31 May 2024 10:23:35 +0000

I once join a team that using postgres and sequelize as their ORM, and they have dozens of migration files, when i try to migrate those files, i got a lot of error that saying the same problem coming from migration files.

some error like:

parent: error: column "column_name" of relation "table_name" does not exist

If i try to fix it one by one it will be a lot of work and time consuming, and if in the future we dont maintenance the migration files regurarly, the same issues will come.

Their solution was giving onboarding member dump files for each databases that used on this project from full timer developer. one of the dump files size was around 900 Mb and when i try to restore the dump files, the data that it contain took around 8 Gb of my SSD. I personally doesnt want my storage get decreased by the large volume of the data from dump files, moreover the process of restoring these files can be time consuming.

As another solution, i make a workaround flow to overcome this issue:

Assume that there is dump folder contains database structure (tables only)
Execute a command to restore the dump file to the database
Execute a command to update the dump file.
If migrate or undo from sequelize then do point 3

This is the solution flowchart:

With this, we can overcome the issue:

Error prone migration process: this solution provides alternative method that is less prone to errors.
Cumbersome manual fixes: as stated, fixing errors on each migration files individually would take a lot of work and time consuming. This solution reduces the efforts to fix each migration files.
Lack of maintenance: This flow providing a mechanism for updating the database structure from and to a dump file.
Quickly get started: With a single command, we can get the project set up with a new blank database, avoiding the need to restore large dump files and saving significant storage space on our systems.

NOTE:
This is just experimenting from my side, and i think there is maybe a better way to handle this problem. Please let me know what do you think about this solution, like: is there any cons on this solution?, how we can improve it?, etc.

Now that we got the idea, how do we implement it with codes? keep reading!

Installation

First thing first we need to install postgresql, make sure its up and running you can also use docker but in this blog i will use postgresql v14 installed using brew.

Now we need to install sequelize, sequlize cli and postgres driver using npm.

npm i sequelize pg && npm i -D sequelize-cli

After installing sequelize now we need to create empty sequelize project using sequelize-cli

npx sequelize-cli init

This will create following folders

config, contains config file, which tells CLI how to connect with database
models, contains all models for your project
migrations, contains all migration files
seeders, contains all seed files

Also dont forget to tell sequelize how to connect to database by adjusting config/config.json.

Lastly we need a folder to store our dump files, lets name it dump.

Now we are ready to create our first migration. Let's create a model named User:

npx sequelize-cli model:generate --name User --attributes firstName:string,lastName:string,email:string

Implementation

We are ready for the implementation, let's create shell script named make and preparing our commands. It will look like this:

#!/bin/sh
case ${1} in
  "db:dump:update")
  ;;

  "db:dump:restore")
  ;;

  "db:migrate")
  ;;

  "db:migrate:undo")
  ;;

  "db:migrate:undo:all")
  ;;

Now our script can handle the commands we need. Let's build the logic one by one:

db:dump:update

This command will create dump file from a database

#!/bin/sh
case ${1} in
  "db:dump:update")
    if test ! -z "${2}";then # Check second argument which will be used as `database_name`
      pg_dump -U postgres -d "${2}" -s -f "dump/pg-${2}-tables.sql"; # Tell postgres to create dump file from a database (tables only)
      {
        echo "CREATE DATABASE ${2} WITH TABLESPACE = pg_default;";
        echo '\\c' "${2};";
        cat "dump/pg-${2}-tables.sql";
      } > temp && mv temp "dump/pg-${2}-tables.sql"; # Concat value of the echos to our dump file (Create database and connect to the created database)
      echo "[!]Bash: UPDATE DUMP ${2} COMPLETED";
    else
      echo "[!]Bash: This command must give parameter. usage ${0} ${1} 'database_name'"
    fi
  ;;
  ...
  ...

db:dump:restore

This command will handle database restoration from a dump file

#!/bin/sh
case ${1} in
  ...
  "db:dump:restore")
    if test ! -z "${2}";then # Check second argument which will be used as `database_name`
      psql -U postgres -a -f "dump/pg-${2}-tables.sql"; # Tell postgres to restore this dump file
      echo "[!]Bash: RESTORE DUMP ${2} COMPLETED";
    else
      echo "[!]Make: This command must give parameter. usage ${0} ${1} 'database_name'"
    fi
  ;;
  ...

db:migrate

Handle flow sequelize migration command

#!/bin/sh
case ${1} in
  ...
  "db:migrate")
    if test ! -z "${2}";then
      if [[ ! -e "dump/pg-${2}-tables.sql" ]]; then # Check dump file if not exist then create one
        touch dump/pg-${2}-tables.sql
      fi
      if psql -lqt | cut -d \| -f 1 | grep ${2}; then # Check is database exist if not then create one
        echo "[!]Bash: Database ${2} exists"
      else
        echo "[!]Bash: Database ${2} doesnt exist";
        createdb -U postgres ${2}
        echo "[!]Bash: Database ${2} created"
      fi
      sequelize-cli db:migrate --debug --url "postgres://postgres:postgres@localhost:5432/${2}" # Sequelize command to migrate migration files into the database
      npm run db:dump:update ${2} # Update dump file from database
    else
      echo "[!]Bash: This command must give ENV parameter. usage: ${0} ${1} 'database_name'";
    fi
  ;;
  ...

db:migrate:undo

Handle flow sequelize undo migration command

#!/bin/sh
case ${1} in
  ...
  "db:migrate:undo")
    if test ! -z "${2}";then
      sequelize-cli db:migrate:undo --debug --url "postgres://postgres:postgres@localhost:5432/${2}" # Sequelize undo migration
      npm run db:dump:update ${2} # Update dump file from database
    else
      echo "[!]Bash: This command must give ENV parameter. usage: ${0} ${1} 'database_name'";
    fi
  ;;
  ...

db:migrate:undo:all

Handle flow sequelize undo migration command

#!/bin/sh
case ${1} in
  ...
  "db:migrate:undo:all")
    if test ! -z "${2}";then
      sequelize-cli db:migrate:undo:all --debug --url "postgres://postgres:postgres@localhost:5432/${2}" # Sequelize undo all migration
      npm run db:dump:update ${2} # Update dump file from database
    else
      echo "[!]Bash: This command must give ENV parameter. usage: ${0} ${1} 'database_name'";
    fi
  ;;
  ...

Final Touch

for the final touch we can store our bash script commands to package.json:

{
    ...
    "scripts": {
        "db:migrate": "./make db:migrate",
        "db:migrate:undo": "./make db:migrate:undo",
        "db:migrate:undo:all": "./make db:migrate:undo:all",
        "db:dump:update": "./make db:dump:update",
        "db:dump:restore": "./make db:dump:restore"
    },
    ...
}

Now we can use the commands using npm.

Execute Commands

All settled up, let's migrate our User model we create earlier on installation section to a database named test, by execute:

npm run db:migrate test

Output:

Database
Shell Output
Dump file

Every time you want to set a project with blank new database, you can restore the dump file, by execute:

npm run db:dump:restore test

Let's test the migration undo command, by execute:

npm run db:migrate:undo test

Output:

Database
Shell Output
Dump file

That's it, you can access full code here, i hope this information helps you in some way. Lastly i want to know how your team handle this issue? please share your experience on the comment section.