liuli-cli: TS/JS SDK CLI 工具

吾辈最初尝试写 JS SDK 发布到 NPM 上，过程中遇到了很多问题，也因此消耗了大量的时间。

包括但不限于以下这些

• 折腾 Rollup 打包
• 折腾 JS 的模块（umd/esm）
• 折腾单元测试
• 折腾 ES6 怎么通过 Babel 编译
• 使用 JS 编写，没有提供类型定义
• 没有进行打包
• 没有编译成 ES5
• 没有单元测试
• 没有 API 文档
• 没有 Linter 和 Prettier 统一格式化

具体的过程可以参考 使用 rollup 打包 JavaScript SDK

吾辈在过程中遇到的一些问题

• 使用 Rollup + Babel 打包出错
• npm 发布后的包安装后无法引用？
• 为什么上传到 GitHub Pages 的静态资源会 404 了呢？有人遇到过么？

吾辈目前所在的公司中的 NPM 库也存在这些问题，内部的 npm 库几乎不能称为一个合格的库，以上的问题基本都存在。所以为了重构公司的 npm 包（主要是为了提供类型定义），就想是否能够把这部分单独抽离成一个脚手架，因而便开发了 SDK cli 供公司的前端 dev 创建一个标准（包含打包、编译、测试、文档、发布）的 SDK，并希望以此抹平不同 NPM 库配置的不一致性。

解决

所以吾辈后来创造了 liuli-cli ，用于简化和统一创建 JS/TS SDK 的步骤。

目前实现的功能如下

• 基本打包支持
• 模块化 umd/es
• jest 单元测试支持
• 代码压缩支持
• babel 支持
• ts 支持
• linter 支持
• prettier 格式化支持
• git 钩子支持
• esdoc
• typedoc
• 许可证选择支持

使用的话也很简单

全局安装 liuli-cli

npm i -g liuli-cli

然后便可以使用命令 li 创建项目

li create 
<project-name></project-name>

目前支持以下三种类型（强烈推荐库的作者使用 TypeScript）

JavaScript 模板
TypeScript 模板
命令行 工具 模板

之后根据引导即可创建一个开箱即用的项目了

反例

让我们看看那些大公司云服务的 JS SDK 是怎样的。

腾讯：提供的 SDK 大多是一个 JS 文件，需要在项目里手动引入，甚至有些是依赖了开源依赖，导致开源依赖使用 npm 管理，而私有服务的 SDK 仍然使用 JS 的方式引入。

• 对象存储
• 腾讯云点播
• 即时通信 IM

讯飞：web 版 demo 明明有 package.json 这种版本控制工具，但却仍然是在一个 HTML 里直接 script 脚本引入，而非使用 npm/yarn 进行依赖管理，而 package.json 里面只是一个 http-server 用以开启一个静态服务器看 demo 罢了。

• 语音听写
• 语音转写
• 实时语音转写

或许在大公司的这些 SDK 的开发者看来，会使用他们这些服务的公司都是小公司，以及一些没有接触过现代前端的开发者，所以都以这种方式提供 SDK。更不要说文档与类型定义，这两项几乎是 JS SDK 标准的需求，他们都没有做好。而且，明明他们的 SDK 也有版本号，甚至给出的 JS SDK 本身便是 umd 的，但实际上却未发布在 npm 或是其他公开的仓库中（作为库的使用者吾辈没有找到）。这些开发者宁愿用户提工单询问，并浪费了大量的沟通时间解决问题也不愿意最开始就将这些做的好一点。

Pass1：文档可能过时，但 Demo 一定是最新的。

Pass2：这行代码不知道做什么的，但没有了就会出错，先放在这里。

当然，或许创建第三方组织可以解决部分这个问题，像是 DefinitelyTyped 那个 ts 的开源项目一样，但问题仍然很多

1. 目标对象不同：DefinitelyTyped 的目标是为了没有 types 的 js 库定义类型，它的目标对象也是开源（大多数时候也是）免费的库。而像是腾讯这些内部服务的 SDK 是收费、不开源的，很难让人免费为其做贡献。
2. 各家都有类似的云服务：提供这种云服务的公司并不止一家，难道要为每一家都添加创建类似的组织么？
3. 安全性问题：第三方组织不能保证每一行贡献的内容一定就和官方的一模一样，就算引入了恶意代码也很难立刻发现。
4. 法律风险：这样做的话是否会被官方发律师函也是未知之数。

当然，也有一些个人为某些云服务创建的 NPM 库

• https://www.npmjs.com/package/xunfeisdk
• https://www.npmjs.com/package/xfy-node

但更多的服务是没有的，而且个人创建的这些库很难保证一直不过时（大多数都是某个项目用了一下罢了）。如果能简化项目的初始化流程，不知是否能让官方发布到 NPM 组织下。

总结

关于使用 CLI 会阻碍人接触更 底层 的知识这点，属于仁者见仁智者见智的事情。毕竟，CLI 能够简化重复的劳动自然是会受到欢迎，前端三大框架也都有自己的 CLI 用于快速创建项目，降低框架的使用门槛，避免接触到一些琐碎的细节而专注于自己的需求开发。

webpack/babel 真的不能说底层，尤其是 webpack，复杂性太高、知识的时效性太短导致现在它的风评并不好。。。

最后，这个项目才写出来没多久，欢迎任何人使用、批评和建议！