〇、前言

對于開發者來說，對外發布代碼制品，主要有兩種形式：構建成完整的應用上架到相關軟件商店中，構建成三方軟件包發布到中心倉庫，鴻蒙生態這邊也是如此，只不過，對于個人開發者來說，上架到華為的鴻蒙應用商店并不容易，因為必須提供軟著證書等有效證件，而這個軟著的申請本來就很費事，相比之下，發布共享包到 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 參數說明代碼倉庫所在，那么別人是無法知道你的實現代碼的。