# 升级指南

tiger 5 的迁移存在一定的成本，如果中途有任何问题可以提交建议反馈 (opens new window)或者咨询：

陈泽韦 - chenzewei01@corp.netease.com

# 说明

由于 Tiger 5.0 相比 4.0 进行了完全的重新设计，原有依赖统一不再使用

迁移过程推荐重新生成的方式：备份原有 server 目录, 使用 npm init @tiger/app server 重新生成模板工程

# 配置迁移

tiger 5 配置使用了自动扫描加载的模式，而 tiger 4 需要手动引入，我们可以先把配置文件声明迁移过去，再在迁移模块的时候将调用方式改掉

首先我们在 tiger 5 的 src/config 目录下创建 custom.ts 文件作为基本配置(你也可以根据情况使用任何和系统自带配置不冲突的名称)

在原有配置中找出有用的配置声明到 custom.ts 中, 其中与原框架相关联的配置可以不用迁移

请勿一股脑有用的和没用的一起拷贝过来，这样使得项目后续难以维护

迁移方式：

tiger 4:

import { config1, config2 } from '../../conf'
// use config1, config2

tiger 5

import { Autowried, Config } from '@tiger/common'

@Service()
export class Example {

    @Autowried
    config: Config;

    index() {
        this.config.get('app.config1', 'defaultConfig')
    }
}

具体 config 属性和方法可以查看配置篇

# 模块迁移

tiger 4 具有 module 的概念，所有模块都是手动声明加载，但是在 tiger 5 中，取消了模块的功能，转而使用框架自动加载

所以我们只需要将 src/modules 下的文件夹拷贝到 tiger 5 的 src/app 目录下，然后我们再对详细的模块进行升级

在每个模块的文件夹内，一般都有 .controller.ts / .service.ts / .module.ts 3种类型结尾的文件，其中 .module.ts 类型的文件我们可以删除掉

请勿拷贝示例默认模块（例如 user、share、static等） —— 即与业务代码不相关的 tiger4 模块

# 控制器

# 依赖

首先我们要删除原来 @tiger/* 的所有依赖, 例如:

import { Get, Post, RequestMapping, RestController } from '@tiger/boot';
import { AjaxResult, QueryContext, RequestContext } from '@tiger/core';

然后我们使用 tiger 5 的依赖:

import { Controller, Get, Post } from '@tiger/common'
import { AjaxResult } from '@tiger/base-provider'

这一步看情况进行引入相应的依赖

# 控制器装饰器

原来的 @RequestMapping() 直接移除（如果有）

原来的 @RestController 替换为 @Controller(prefix), 其中 prefix 参数一般就是原来的 @RequestMapping 的参数

原来 prefix 参数中，可能含有 contextPath 变量，这是原来配置不支持 baseUrl 才手动加上的，所以这个我们是不需要的

例如： ${contextPath}${xhrPath}/users => /xhr/users

# 请求上下文

tiger 4 中，我们是直接使用的 koa 的 ctx 作为控制器方法的参数的，但是在 tiger 5 中，我们是通过 Request 对象来获取请求信息的

所以我们需要删掉控制器方法的 ctx 参数，使用依赖注入的方式注入 Request 实例:

tiger 4:

export class ExampleController {
    @Get()
    index(ctx: any) {
        console.log(ctx.request.body)
        console.log(ctx.querstring)
       // 等等 ctx 属性
    }
}

tiger 5:

export class ExampleController {
    @Get()
    index(request: Request) {
        console.log(request.body)
        console.log(request.querystring)
       // 等等 request 属性
    }
}

具体 request 属性和方法可以查看 Request 篇

# 响应

tiger 5 使用 return 的方式返回响应输出

我们需要将 ctx.body = data 替换为 return data（注意 return 会不会改变代码执行流程导致提前退出）

如果是 ctx.body = AjaxResult.foo() 的方式返回的， tiger 5 也支持直接支持 return AjaxResult.foo()

注意： tiger 5 的 AjaxResult 是从 @tiger/base-provider 业务组件包引入的， API 保持不变

# Service

tiger 4 的 service 是由 @Service 标记，Tiger 5 中使用 @Service() （统一需要函数调用的方式）

关于 url

tiger 4 中我们有 getServiceUrl 方法来获取具体的 url, 但是用起来繁琐麻烦，Tiger 5 我们进行了重新设计

import { getServiceUrl } from '@tiger/base-provider'
// 根据 serviceCode 自动生成标准的 url
// 输出：
// 本地环境 dev: `http://test.yx.mail.netease.com/${serviceCode}`,
// 开发环境 betayun: `http://dev.yx.localhost:8550/proxy/dev.${serviceCode}.service.mailsaas`,
// 测试环境 test: `http://127.0.0.1:8550/proxy/test.${serviceCode}.service.mailsaas`,
// 线上环境 online: `http://127.0.0.1:8550/proxy/online.${serviceCode}.service.mailsaas`,
// 回归环境 regression: `http://127.0.0.1:8550/proxy/regression.${serviceCode}.service.mailsaas`,
getServiceUrl('example-service-code')

如果不是遵循现有标准的服务地址，我们可以通过 urls 参数来实现自定义：

getServiceUrl('example-service-code', urls: {
    dev?: string;
    betayun?: string;
    test?: string;
    online?: string;
    regression?: string;
})

# 中间件迁移

所有 tiger 4 模板工程自带的中间件都不需要迁移

如果有自定义的 koa 中间件，推荐使用 tiger 5 的中间件模式重构

具体 middleware 使用方法可以查看 Middleware 篇