# title: Plugin

Plugin mechanism is a major feature of our framework. Not only can it ensure that the core of the framework is sufficiently streamlined, stable and efficient, but also can promote the reuse of business logic and the formation of an ecosystem. In the following sections, we will try to answer questions such as

# Why plugins?

Here are some of the issues we think that can arise when using Koa middleware:

  1. Middleware loading is sequential and it is the user's responsibility to setup the execution sequence since middleware mechanism can not manage the actual order. This, in fact, is not very friendly. When the order is not correct, it can lead to unexpected results.
  2. Middleware positioning is geared towards intercepting user requests to add additional logic before or after such as: authentication, security checks, logging and so on. However, in some cases, such functionality can be unrelated to the request, for example, timing tasks, message subscriptions, back-end logic and so on.
  3. Some features include very complex initialization logic that needs to be done at application startup. This is obviously not suitable for middleware to achieve.

To sum up, we need a more powerful mechanism to manage, orchestrate those relatively independent business logic.

# The relationship between middleware, plugins and application

A plugin is actually a "mini-application", almost the same as an app:

Their relationship is:

# Using plugins

Plugins are usually added via the npm module:

$ npm i egg-mysql --save

** Note: We recommend introducing dependencies in the ^ way, and locking versions are strongly discouraged. **

"dependencies": {
"egg-mysql": "^ 3.0.0"

Then you need to declare it in the config / plugin.js application or framework:

// config / plugin.js
// Use mysql plug-in
exports.mysql = {
enable: true,
package: 'egg-mysql'

You can directly use the functionality provided by the plugin:

app.mysql.query(sql, values);

# Configuring plugins

Each configuration item in plugin.js supports:

# Enabling/Disabling plugins

The application does not need the package or path configuration when using the plugins built in the upper framework. You only need to specify whether they are enabled or not:

// For the built-in plugin, you can use the following simple way to turn on or off
exports.onerror = false;

# Environment configuration

We also support plugin.{Env}.js, which will load plugin configurations based on Runtime.

For example, if you want to load the plugin egg-dev only in the local environment, you can install it to devDependencies and adjust the plugin configuration accordingly.

// npm i egg-dev --save-dev
// package.json
  "devDependencies": {
    "egg-dev": "*"

Then declare in plugin.local.js:

// config / plugin.local.js
exports.dev = {
enable: true,
package: 'egg-dev'

In this way, npm i --production in the production environment does not need to download theegg-dev package.

** Note: **

# Package name and path

// config / plugin.js
const path = require ('path');
exports.mysql = {
  enable: true,
  package: path.join (__ dirname, '../lib/plugin/egg-mysql'),

# Plugin configuration

The plugin will usually contain its own default configuration, you can overwrite this in config.default.js:

// config / config.default.js
exports.mysql = {
client: {
host: 'mysql.com',
port: '3306',
user: 'test_user',
password: 'test_password',
database: 'test'

Specific consolidation rules can be found in [Configuration] (. / Config.md).

# Plugin list

# Developing a plugin

See the documentation plugin development.