〇、前言

对于开发者来说，对外发布代码制品，主要有两种形式：构建成完整的应用上架到相关软件商店中，构建成三方软件包发布到中心仓库，鸿蒙生态这边也是如此，只不过，对于个人开发者来说，上架到华为的鸿蒙应用商店并不容易，因为必须提供软著证书等有效证件，而这个软著的申请本来就很费事，相比之下，发布共享包到 ohpm 中心仓库，就显得简单可行了。

如图所示，我已经成功上架两个软件包到 ohpm 中心仓库上了，因而积累了一定的经验，下面就让我向大家阐述如何规范地开发鸿蒙共享包。

一、了解评分规则

如上所述，ohpm 中心仓有一套针对每个发布到仓库中的软件包的评分规则，满分 50 分，共 5 种中得分规则。而我已经上架的软件包，并未针对得分规则进行适配开发，因而只获得了 15 分，也因此我重新发布了 lib_easyrouter v1.1.0（正在上架审核）。

评分高的软件包，想必理所当然地会获得更高的排名，他人在搜索的时候，更容易出现在第一分页中。

总的来说，遵循 ohpm 软件包评分规则，既是我们提高自己软件包的排名的方法，也是我们进行规范开发的依据。

二、规范开发共享包

1、规范开源协议名称写法

既然，ohpm 中心仓有针对开源协议的评分点，那么，我们在选择的时候，就要有的放矢；此前，我习惯性地使用 Mulan PSL v2 作为协议名称，但是这种写法并不符合SPDX规范，导致即便自己选择的开源协议就在 SPDX License List中，也无法被 ohpm 中心仓的协议扫描工具所识别：

因此，我们需要将 oh-package.json5文件中的 license 字段值，正确填写为 MuLanPSL-2.0，类似的，其他开源协议的名称填写，也应当按照 SPDX License List 中列举的样子去填写；如果你使用的开源协议，在 SPDX License List 中找不到，那么，说明它就不是 SPDX 规范的协议，此时，最好换一个。

2、将 oh-package.json5 文件补充完整

在 lib_easyrouter 的得分明细中，可以看到因为 oh-pakage.json 文件缺少内容而被扣分，主要就是少了 keywords 和 homepage，所以，针对性补充内容之后，就得到了一份内容完整的 oh-package.json5 文件：

{"name": "lib_easyrouter","version": "1.1.0","description": "一个以动态加载为核心实现跨模块页面路由功能的路由工具包","main": "Index.ets","keywords": ["跨模块路由", "动态加载"],"homepage": "https://gitee.com/pengyoucongcode/EasyRouter","author": "***","license": "MulanPSL-2.0","repository": "https://gitee.com/pengyoucongcode/EasyRouter","dependencies": {"lib_log": "^1.0.0"}
}

3、补充 example 目录

lib_easyrouter 另一个失分的地方，就是因为缺少 example 目录，实际上，完善的软件包也应当有一个提供功能演示的 example，所以，我在 v1.1.0 版本的 lib_easyrouter 中，针对性地加上了 example：

4、基本的 README 和 CHANGELOG

如果你对自己发布的 ohpm 包，在中心仓上最终能获得多少分并不在乎，但为了让软件包能够成功上架，必须提供基本的说明文档，也就是 README.md 和 CHANGELOG.md。

三、ohpm 包的源码隔离特性

与 Maven、PyPi 和 NPM 等三方包管理系统所不同的是，ohpm 并不会直接将源码暴露给其他引用者：

以我自己发布的另一个鸿蒙共享包 lib_log 为例，可以看到下载的所谓源码，都是 .d.ets 文件，而这种文件就跟 .d.ts 文件一样，只是一种声明文件，并不会包含具体的实现逻辑，类似于 C/C++ 的头文件，所以，如果你没有在 oh-package.json5 使用 repository 参数说明代码仓库所在，那么别人是无法知道你的实现代码的。