@serverless-devs/s 2.0.96 → 2.0.97-beta.1

package/docs/zh/yaml.md

@@ -1,207 +0,0 @@
-# 描述文件（Yaml）规范
-
-> 当前文档遵循 [Serverless User Model](../../spec/zh/0.0.1/serverless_user_model/readme.md) 和相关规范。
-
-- [描述文件简介](#描述文件简介)
-- [描述文件格式/规范](#描述文件格式规范)
-    - [元数据](#元数据)
-    - [变量赋值](#变量赋值)
-    - [服务顺序](#服务顺序)
-    - [行为描述](#行为描述)
-
-## 描述文件简介
-
-在非`cli`模式下，进行应用的操作、组件的使用，需要按照 Serverless Devs 的规范，提供相对应的资源/行为描述文件，且该文件还需要符合以下条件：
-
-- 拓展名可以是`.yaml`或`.yml`
-- 格式必须符合[Yaml规范](https://yaml.org/spec/1.2.2/)
-
-> 👉 对于需要通过描述文件进行环境隔离的项目，建议将文件命名为 `s-${ENV}.yaml` 或 `s-${ENV}.yml` 格式。 例如：`s-prod.yaml`。
-
-在默认情况下，Serverless Devs 开发者工具会默认该描述文件的名称为`s.yaml`或`s.yml`，且`s.yaml`的优先级大于`s.yml`， 即在一个 Serverless 应用下，同时出现`s.yaml`与`s.yml`时，系统会优先识别和使用`s.yaml`。
-
-当然，开发者也可以通过`-t, --template  [templatePath]`进行指定，例如，在某应用在生产环境下的描述文件名为`s-prod.yml`，则可以在执行相关命令时，增加参数`-t s-prod.yml`或者`--template s-prod.yml`。
-
-## 描述文件格式/规范
-
-关于 Serverless Devs 所支持的资源/行为描述文件基本格式为：
-
-```yaml
-edition: 1.0.0          #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范
-name: applicationName   #  应用名称
-access: xxx-account1    #  秘钥别名
-
-vars: # [全局变量，提供给各个服务使用]
-  Key: Value
-
-Service: # 可以包括多个服务
-  ServiceName: # 服务名称
-    access: xxx-account1      #  秘钥别名，如果和项目的access相同，可省略
-    component: componentName  #  组件名称
-    props: serviceProp        #  组件的属性值
-    actions: serviceActions   #  自定义执行逻辑
-```
-
-例如，一个相对完整的 Yaml 案例可以是：
-
-```yaml
-edition: 1.0.0        #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范
-name: FullStack       #  项目名称
-access: xxx-account1  #  秘钥别名
-
-vars: # [全局变量，提供给各个服务使用]
-  logo: https://image.aliyun.com/xxxx.png
-
-services:
-  nextjs-portal: #  服务名称
-    access: xxx-account1  #  秘钥别名，如果和项目的access相同，可省略
-    component: vue-component  # 组件名称
-    props: #  组件的属性值
-      src: ./frontend_src
-      url: url
-    actions: # 自定义执行逻辑
-      pre-deploy: # 在deploy之前运行
-        - run: s exec -- publish  # 要运行的命令行
-          path: ./backend_src # 命令行运行的路径
-        - run: s build  # 要运行的命令行
-          path: ./backend_src # 命令行运行的路径
-      post-deploy: # 在deploy之后运行
-        - run: s clean
-          path: ./frontend_src
-
-  assets:
-    component: static
-    props:
-      cache-control: "public, max-age=604800, immutable"
-      www: "./public"
-
-  express-blog:
-    component: express
-    props:
-      app: ./express-blog
-      url: ${vars.domain}
-    actions:
-      pre-deploy:
-        - run: npm run build
-          path: ./express-blog
-
-  gateway:
-    component: serverless-gateway # 路由组件：HTTP URL和服务之间的映射规则
-    props:
-      routes:
-        - route: /~assets
-          value: ${assets.output.url}
-        - route: /
-          value: ${nextjs-portal.output.url}
-          index: index.html
-        - route: /~portal
-          value: ${nextjs-portal.output.url}
-          inex: index.html
-        - route: /~blog
-          value: ${express-blog.output.url}
-```
-
-### 元数据
-
-在该格式中：
-
-| 参数名 |  代表含义   | 
-|  ----  | ----  | 
-| edition  | 命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范 | 
-| name  | 应用名称 | 
-| access  | 秘钥别名，可以使用通过[config命令](./command/config.md#config-add-命令)配置的密钥信息，以及[配置到环境变量的密钥信息](./command/config.md#通过环境变量配置密钥信息) |
-| vars  | 全局变量，提供给各个服务使用，是一个Key-Value的形式 |
-| Service  | 应用所包含的服务，是一个Key-Value的形式 |
-
-关于Service参数：
-
-| 参数名 |  代表含义   | 
-|  ----  | ----  | 
-| access  | 秘钥别名，如果和项目的access相同，可省略 | 
-| component  | 组件名称 | 
-| actions  | 自定义执行逻辑 |
-| props  | 组件的属性值 |
-
-### 变量赋值
-
-Serverless Application模型对应的Yaml文件支持多种变量格式：
-
-- 获取当前机器中的环境变量：${env(环境变量)}，例如${env(secretId)}
-- 获取外部文档的变量：${file(路径)}，例如${file(./path)}
-- 获取全局变量：${vars.*}
-- 获取其他项目的变量：${projectName.props.*}
-- 获取Yaml中其他项目的结果变量：${projectName.output.*}
-
-### 服务顺序
-
-如果一个Serverless Application模型对应的Yaml文件中有过多的服务，系统会默认分析部署顺序，该部署顺序分为两个步骤：
-
-1. 分析项目中的依赖关系
-2. 有依赖关系的按照依赖关系从前到后部署，无依赖关系的按Yaml配置的从上到下部署
-
-### 行为描述
-
-在Serverless Application模型对应的Yaml文件中，可以针对服务，提供对应的行为操作，其基本格式是：
-
-```yaml
-actions: # 自定义执行逻辑
-  pre-命令: # 在命令之前运行
-    - run: command  # 要运行的操作
-      path: ./path # 运行操作的路径
-  post-命令: # 在命令之后运行
-    - run: command  # 要运行的操作
-      path: ./path # 运行操作的路径
-```
-
-例如：
-
-```yaml
-actions: # 自定义执行逻辑
-  pre-deploy: # 在deploy之前运行
-    - run: s exec -- publish  # 要运行的命令行
-      path: ./backend_src # 命令行运行的路径
-    - run: s build  # 要运行的命令行
-      path: ./backend_src # 命令行运行的路径
-  post-deploy: # 在deploy之后运行
-    - run: s clean
-      path: ./frontend_src
-```
-
-当Serverless Devs开发者工具执行到该服务时，会在进行相关的命令之行之前，优先按照顺序执行`pre-命令`的操作，所有内容完成执行之后，再执行`post-命令`的操作。
-
-以下面的Yaml为例：
-
-```yaml
-edition: 1.0.0        #  命令行YAML规范版本，遵循语义化版本（Semantic Versioning）规范
-name: FullStack       #  项目名称
-
-services:
-  nextjs-portal: #  服务名称
-    access: xxx-account1  #  秘钥别名，如果和项目的access相同，可省略
-    component: vue-component  # 组件名称
-    props: #  组件的属性值
-      src: ./frontend_src
-      url: url
-    actions: # 自定义执行逻辑
-      pre-deploy: # 在deploy之前运行
-        - run: s exec -- publish  # 要运行的命令行
-          path: ./backend_src # 命令行运行的路径
-        - run: s build  # 要运行的命令行
-          path: ./backend_src # 命令行运行的路径
-      post-deploy: # 在deploy之后运行
-        - run: s clean
-          path: ./frontend_src
-```
-
-当开发者在当前应用下执行了`deploy`命令，系统将会按照以下顺序进行操作：
-1. 在`./backend_src`目录下执行`s exec -- publish`
-2. 在`./backend_src`目录下执行`s build`
-3. 调用组件`vue-component`的`deploy`方法，并将`props`和项目的基本信息传入到组件`vue-component`的`deploy`方法中
-4. 在`./frontend_src`目录下执行`s clean`
-
-以上顺序仅适用于整个流程没有出错的前提下，如果流程出现错误，系统将会进行报错，并终止后续流程的执行。
-
-
------------
-
-> 在一个应用下，如何一键部署整个应用？又或者如何只部署应用中的某个Service？可以参考[自定义命令使用指南](./command/custom.md)

package/docs/zh/yaml_and_cli.md

@@ -1,67 +0,0 @@
-# Yaml 模式 Cli 模式对比
-
-Serverless Devs 开发者工具从根本上提供了两种使用方法。
-- Yaml模式：需要依赖资源描述文档进行操作的模式
-- Cli模式：可以在任何目录下直接执行，而不需要依赖资源描述文档；
-
-这两者的核心区别是：
-
-1. 如果想要使用 Yaml 模式，在当前目录下，必须要有`s.yaml`/`s.yml`文件，或通过`-t`/`--template`指定的资源部描述文件；
-2. 如果想要试用 Cli 模式，则必须是 `s cli 组件名 方法 参数`的格式进行，此时不需要 Yaml 文件；
-
-举一个非常简单的例子，如果有一个应用的资源描述文件`s.yaml`如下：
-
-```yaml
-name: myApp
-edition: 1.0.0
-access: "myaccess"
-
-services:
-  website-starter:
-    component: devsapp/website
-    props:
-      bucket: testbucket
-  backend-starter:
-    component: devsapp/demo
-    props:
-      service:
-        name: serviceName
-      function:
-        name: functionName
-      region: cn-hangzhou
-```
-
-此时，可以执行`s deploy`进行`myApp`应用部署，如果执行`s backend-starter deploy`则可以进行`myApp`应用下的`backend-starter`项目/服务部署。
-
-此时，部署过程中，所需要的相关参数，可以通过该 Yaml 文件进行读取。
-
-但是，在某些情况下，并不方便直接使用 Serverless Devs 规范的 Yaml 文件（例如，将线上资源同步到本地，或者要将 Funcraft 的 Yaml 转换成为 Serverless Devs 的 Yaml），此时可以选择纯命令行形式，即`s cli`模式。
-
-在 `s cli` 模式下，由于不会读取 Yaml 等资源描述文件，所以很多参数都需要自行填写，这时的填写方法有两种：
-
-1. 通过 `s cli` 天然支持的 `-p`/`--prop` 参数，进行相关 Yaml 参数的赋值，例如上述案例的`s backend-starter deploy`，此时可以改写成：
-    ```shell script
-    s cli devsapp/demo -p "{\"service\":{\"name\":\"serviceName\"},\"function\":{\"name\":\"functionName\"},\"region\":\"cn-hangzhou\"}"
-    ```
-2. 通过 demo 组件本身所支持的一些参数，例如通过`s cli devsapp/demo -h`，可以得到帮助信息，部分内容如下：
-    ```shell script
-      --region [region]               [C-Required] Specify the fc region, value: cn-hangzhou/cn-beijing/cn-beijing/cn-hangzhou/cn-shanghai/cn-qingdao/cn-zhangjiakou/cn-huhehaote/cn-shenzhen/cn-chengdu/cn-hongkong/ap-southeast-1/ap-southeast-2/ap-southeast-3/ap-southeast-5/ap-northeast-1/eu-central-1/eu-west-1/us-west-1/us-east-1/ap-south-1  
-      --service-name [serviceName]    [C-Required] Specify the fc service name  
-      --function-name [functionName]  [Optional] Specify the fc function name   
-    ```
-    此时，就可与通过下面的命令实现上述功能：
-    ```shell script
-    s cli devsapp/demo --region cn-hangzhou --service-name serviceName --function-name functionName
-    ```
-
-## 特点对比
-
-| 模式 | 使用方法 | 优势 |  劣势 |  适用场景  |
-| --- | --- | --- | --- | --- |
-| Yaml模式 | 在具有符合Serverless Devs规范，且存在资源/行为描述的Yaml文件的应用目录下，执行组件对应的命令，即可直接使用，例如`s deploy`，`s servicename build`等 | 可以一键部署一个完整的应用（例如，某个应用中规定了多个Service，可以通过该命令一键部署）；同时，通过资源/行为描述文档，可以更佳简单，清晰的对应用进行描述； | 需要学习Yaml的规范，且在某些时候与一些自动化流程进行结合，会比较复杂； | 部署、运维等操作，尤其是批量操作时更为合适； |
-| 纯Cli模式 | 在任何目录下，通过子命令`cli`进行触发，同样适用全部组件，例如`s cli deploy -p "{/"function/": /"function-name/"}"`，`s cli fc-api listFunctions --service-name my-service` | 相对来说可以更加简单，快速上手工具，并且可以非常简单的与自动化流程进行结合，降低了Yaml格式/规范的学习难度 | 对于一些复杂项目而言，需要在命令行中写过多的参数，出错的概率会比较高； | 更适合项目的管理，源自化操作 |
-
-## 设计思路
-
-> ❓ 为什么要同时存在 Yaml 模式和 Cli 模式？   
-> 💬 因为在长期的实践过程中，我们发现通过 Yaml 进行资源描述会相对来说更简单和方便，例如 K8S 等也都是通过 Yaml 进行资源描述的；但是，在某些情况下，Yaml 文件也可能成为一种负担，例如想要查看某个服务下的函数列表，查看某个地区下的服务列表，因为这样一个简单的事情要额外的去完成一个 Yaml 文件，就显得过于臃肿，所以，在 Serverless Devs 项目中，同时保留了两种使用方法。

package/jest.setup.ts

@@ -1,37 +0,0 @@
-/** @format */
-import path from 'path';
-import os from 'os';
-import core from './src/utils/core';
-const { fse: fs, jsyaml: yaml } = core;
-import logger from './src/utils/logger';
-
-jestBeforeDetection();
-
-function jestBeforeDetection() {
-  if (!detectioIsExist('.s/access.yaml')) {
-    logger.error(`Failed to execute:\n
-  ❌ Message: Please install S component
-  😈 If you have questions, please tell us: https://github.com/Serverless-Devs/Serverless-Devs/issues\n`);
-    process.exit(1);
-  }
-  if (Object.keys(getAccessFile()).length === 0) {
-    logger.error(`Failed to execute:\n
-    ❌ Message: Please configure your Secret
-    😈 If you have questions, please tell us: https://github.com/Serverless-Devs/Serverless-Devs/issues\n`);
-    process.exit(1);
-  }
-}
-
-function detectioIsExist(road) {
-  return fs.existsSync(getPath(road));
-}
-
-function getAccessFile() {
-  const accessFile = getPath('.s/access.yaml');
-  const accessFileInfo = yaml.load(fs.readFileSync(accessFile, 'utf-8') || '{}');
-  return accessFileInfo;
-}
-
-function getPath(road) {
-  return path.join(os.homedir(), road);
-}

package/spec/readme.md

@@ -1,59 +0,0 @@
-# Serverless Devs Model(SDM)
-
-Serverless Devs Model(SDM，下文简称SDM)的官方文档，主要用于介绍 SDM 的模型详情与相关规范。
-
-Serverless Devs Model(SDM) 是一种与厂商 FaaS 平台无关的 Serverless 架构工具链模型，用于定义通用的 Serverless 架构工具使用标准，让开发者更专注于业务逻辑，提升 Serverless 应用开发、部署、运维效率，通过该模型，开发者可以通过一种更灵活、更通用的方法使用不同云厂商以及开源的 Serverless 产品，进而更高效、更简洁、更便利的实现 Serverless 应用管理。
-
-## 介绍
-
-"Serverless应用的开发人员应该更关心业务代码，而不需要更多精力去适应不同Serverless平台（包括不同厂商的开发者工具学习，不同功能的使用等）。"
-
-![](https://serverless-article-picture.oss-cn-hangzhou.aliyuncs.com/1631771269638_20210916054752754202.png)
-
-### 为什么需要工具模型
-
-就目前来看 Serverless 架构厂商锁定严重，不同厂商会有不同的工具，不同的使用途径，这使得开发者在应用开发的过程中，以及在混合云部署、运维的过程中面临了诸多困难：
-
-- **学习难度大**：开发者要针对不同的云厂商学习不同的工具使用方法，接受不同 Serverless 平台的使用方法，包括不限于发布部署、运维、构建等众多流程；
-- **工具扩展差**：很多 Serverless 平台提供的开发者工具，往往是由开发团队提供对应的功能，使用者仅具有使用的功能，如需进行部分的定制化能力，或拓展能力，是难以扩展的；
-- **适配成本高**：多云部署，业务迁移是生产过程中常见的行为，由于 Serverless 架构厂商锁定严重导致多云部署、业务迁移时学习成本以及转换成本非常高；
-
-在 Serverless Devs Model(SDM) 中，我们提出了一种以应用为中心，以组件为途径的方法：
-
-- **应用概念优先**：该模型将会以应用纬度进行项目管理，而不再单单以资源形式进行项目管理，这将对应用的开发和定义有着更清晰的定义；
-- **组件化功能透出**：该模型将不会提供任何与 Serverless 平台相关的功能，这些所有的功能都将会通过组件，以一种可插拔的形式对开发者透出，Serverless 开发者可以在一个应用中，同时使用多种组件，实现一个完整的应用部署，甚至可以同时实现混合云的部署；
-- **通用功能的抽象**：该模型将会推进 Serverless 架构在不同平台下的通用功能的抽象，例如应用的构建、调试功能等都可以通过组件形式进一步抽象为更多的 Serverless 开发者提供开发支持；
-
-:trophy: 我们的目标是：
-
-- 开发者可以通过一套工具更简单、更方便、更快速的使用不同 Serverless 平台的产品/功能，包括不限于构建、调试、部署、运维等不同的流程或者阶段；
-- 开发者可以以应用的视角去看到 Serverless 应用，甚至是可以通过一行命令将 Serverless 应用部署到不同的 Serverless 平台；
-- 开发者可以非常简单的进行Onboarding的流程，可以体验一致的进行不能上层能力的抽象；
-
-## 模型学习
-
-模型本身由 Serverless Devs 项目驱动，并作为一组版本话 API 文档进行维护，如下所示：
-
-- [v0.0.1 (Serverless Devs v2.x)](zh/0.0.1/readme.md)
-
-## 社区
-
-### 贡献
-
-> 有关详细信息，请参阅[贡献指南](../CONTRIBUTING.md)。
-
-针对 spec 的贡献也可以参考以下内容：
-- 将 Serverless Devs 仓库 fork 到自己的账号/组织下；
-- 对 spec 内容进行修改，更新，完善；
-- 对对应版本下的`readme.md`进行更新，添加自己到`作者`->`贡献者`中；
-- 提`Pull requests`到仓库`Serverless-Devs/Serverless-Devs`的`docs`分支下；并添加 [Anycodes](https://github.com/anycodes) 、 [hanxie](https://github.com/hanxie-crypto) 等作为Reviewers，同时在Comment中填写好更新理由；
-
-### 会议时间
-
-- 等待社区反馈
-
-## 协议
-
-Serverless Devs 是一个遵循 [MIT](../LICENSE) 协议的开源项目。
-
-Serverless Devs 使用的 node_modules 以及其他第三方的依赖库都可能有其遵循的协议，我们推荐你阅读并了解这些协议，因为其中的条款可能和 MIT 协议中的不完全相同。

package/spec/zh/0.0.1/readme.md

@@ -1,47 +0,0 @@
-# Serverless Devs Model(SDM) v0.0.1 文档
-
-- 版本：v0.0.1
-- 作者：
-    - 发起人：
-        - [Anycodes](https://github.com/anycodes)
-    - 贡献者：
-        - [hanxie](https://github.com/hanxie-crypto)
-        - [git-qfzhang](https://github.com/git-qfzhang)
-- 时间：2021.9.16
-- 内容：
-    - [Serverless Registry Model](./serverless_registry_model)
-    - [Serverless Package Model](./serverless_package_model)
-    - [Serverless User Model](./serverless_user_model)
-
-## 简介
-
-Serverless Devs Model(SDM) v0.0.1 文档是由 Serverless Devs 社区发起编写的第一版关于 Serverless 工具链的规范模型文档。该文档将会主要通过 Serverless 工具链体系中的 **Registry模型**，**开发工具模型**以及**用户使用模型**三个模块进行撰写。
-
-![](https://serverless-article-picture.oss-cn-hangzhou.aliyuncs.com/1631773288370_20210916062130083859.png)
-
-由上图所示，Serverless Devs 的开发角色分为两部分：
-- **Package developer**：指的是开发/贡献符合 Serverless Package Model 规范的组件或者公开的应用案例；这部分开发者通常会吧应用发布到对应的 Registry 上；
-- **Serverless developer**：指的是 Serverless 应用的开发者，这部分开发者通过使用 Package developer 开发的公共应用案例或者引用不同的组件，将自己的应用部署到不同的 Serverless 平台，或者对应用进行不同的处理，包括不限于构建、观测、压测、调试等；
-
-同时通过上图也可以看到两个比较明显的词汇：Component和Application：
-- **Component**：指的是组件；是由 Package developer 开发并发布的符合 Serverless Package Model 规范的一段代码，通常这段代码会在应用中被引用，并在 Serverless Devs 开发者工具 中被加载，并按照预定的规则进行执行某些动作。例如，将用户的代码部署到 Serverless 平台；将 Serverless 应用进行构建和打包；对 Serverless 应用进行调试等；
-- **Application**：指的是应用；可以由 Package developer 公开发布到 Registry，以供更多人学习和使用，例如某位贡献者贡献了一个猫狗识别的案例到Registry；也可以由 Serverless developer 开发，例如某人开发了一个 人脸识别的应用；通常情况下一个应用可以引用一个或者多个组件，并通过 Serverless Devs 开发者工具 工具部署到 Serverless 平台，例如我开发了一个猫狗识别的应用，在这个应用中引用了 Lambda 组件帮助我将部分业务逻辑部署到 FaaS 平台，同时我也引用了 Website 组件帮助我把前端业务代码部署到对象存储中；
-
-通过上图，同样也可以看到 Serverless Devs Model 包含了以下三个模块： 
-
-- **Registry模型**：一个开放的 Serverless Registry Model。Package的开发者可以将自己开发的组件，或者待分享的应用发布到该平台。该平台可以使用目前 Serverless Devs 所支持的 Github Resitry， Gitee Registry， Serverless Registry，也可以按照该规范搭建私有的 Registry 以完成部分能力。详情可以参考[Registry模型文档](serverless_registry_model)
-- **开发包模型**：一个关于 Serverless Package 的规范。Package developer 需要遵循该规范进行组件的开发或者应用的共享，否则将无法被 Serverless Devs 开发者工具 工具所识别和加载，也无法被 Application 所引用，并实现预期的功能。详情可以参考[开发包模型](serverless_pacakge_model)
-- **用户使用模型**：Serverless developer 在进行应用开发时所需要遵守的约定，以确保 Serverless Devs 开发者工具 可以准确识别相对应的内容，并按照预期加载对应的 Component，完成预期的功能。详情可以参考[用户使用模型文档](serverless_user_model)
-
-## 社区
-
-### 贡献
-
-有关详细信息，请参阅[贡献指南](../../../CONTRIBUTING.md)。
-
-
-## 协议
-
-Serverless Devs 是一个遵循 [MIT](../../../LICENSE) 协议的开源项目。
-
-Serverless Devs 使用的 node_modules 以及其他第三方的依赖库都可能有其遵循的协议，我们推荐你阅读并了解这些协议，因为其中的条款可能和 MIT 协议中的不完全相同。

package/spec/zh/0.0.1/serverless_package_model/1.purpose_and_goals.md

@@ -1,3 +0,0 @@
-# 目的和目标
-
-Serverless Package Model(简称SPM，下文将使用SPM代替)的目标是定义一种 Serverless Package 开发模型以及开发者规范；核心目的是基于这套模型或者规范所开发的项目，可以被 Serverless Registry 所接受，并且被 Serverless Devs 开发者工具所识别，按照 Serverless 开发者的预期实现实现预定的功能。

package/spec/zh/0.0.1/serverless_package_model/2.overview_and_terminology.md

@@ -1,14 +0,0 @@
-# 概述和术语
-
-Serverless Package Model(SPM) 是 Package 开发者所需要使用的模型，以及遵循的规范。从形态组成纬度包括应用与组件两部分；同文件树组成来看包括用于自描述的`publish.yaml`文件，以及业务代码`：
-
-![](https://serverless-article-picture.oss-cn-hangzhou.aliyuncs.com/1631934027954_20210918030028156081.png)
-
-
-### Package与Package Model
-
-相对来说，Package是一个实际的产物，由规范的代码组成，目的是完成某个功能或者表示一个案例；而Package Model相对来说是抽象的存在，表示的是一种规范与规则。
-
-- Package是由指符合 SPM 规范的代码，其目标是用来实现模型功能，包括不限于部署业务逻辑到 Serverless 平台，调试 Serverless 应用代码等；
-- Package Model 是 Serverless Devs 的 Package 开发规范，只有按照该模型，遵循该规范的 Serverless Package 才可以被 Serverless Devs 开发者工具 所识别，并且可以成功的发布在符合 Serverless Registry Model 规范的 Serverless Registry 平台上；
-