前言
最近做的一件事是开发tpns的通用模块，并根据git工程将其发布到Unity的PackageManager上。 俗话说，能做的人不难，做不到的人做不到。 由于事先没有文档存在，因此在发布阶段大约需要一天的时间(实际上30分钟就结束了)，我们将继续了解系统，并将其发布以加深印象。 另外，我希望这篇文章能帮助我们不要踩到很多人的漏洞。
首先谈谈插件包的规格
开发时，发布package的过程不明确，因此在发布package时必须进行调整，修改文件目录，同时也修改代码。 每次调整都可能带来人为错误、修正、测试、修正……，最直观的影响是开发时间延长，整个模块的开发效率。 人为错误是不可避免的。 通过一些规范的约定，可以尽量避免那些问题吗？ 我相信根据自己的经验，可以总结以下四点，解决大部分问题。
1 .在代码中统一设置命名空间
模块中的所有代码逻辑必须位于一个或多个自定义命名空间之下。
package旨在为多个项目提供服务，不可避免地会使用相同的名称，如主项目、管理器等。 package的开发不会影响使用它的项目。 所以，引入命名空间是一个非常好的战略。
2 .项目只有一个相关渠道
我开发的模块在资产下有这样四个文件夹Demo、Document、幸福的蓝天和运行时。 Runtime:这里放置的机型是保证模块工作的内容。
Demo :与Demo相关的资源、代码、配置……放在这里。
Document :不影响项目运行且具有说明性性质的文档放在此处。
幸福蓝天：所有编辑器代码都应该放在下面，而其他地方不应该出现与编辑器相关的代码。
3.demo与核心业务分离
其目的是防止demo进入正式项目。 一般来说，虽然demo不大。 我这个人有强迫症，认为这个demo与项目无关，但不应该进包里。
4.demo背面和模块内不放置dll
与命名空间一样，您将面临与正在开发的项目重复的情况。 典型的解决方案是在发布时不导入dll，而是由使用的项目自己导入。 您可以导入dll，也可以将dll打包并发布为新package以导入该package。
发布流程
创建package.json文件
在发布的根目录下创建package.json文件，并设置项目信息。 此目录可以是您unity项目的Assets文件，也可以是任何内容的文件夹。
{
' name ' : ' com.rone.test package '，
' display name ' : ' mytest package '，
'描述' : ' thisismytestpackage '，
'版本' : '1.0.0'，
' unity': '2018.3 '，
'许可证' : ' MIT '，
'从属关系' : {
}
}
根据实际情况创建. asmdef文件。 运行时和幸福的蓝天分别创建相应的. asmdef文件。 如上所述，将所有编辑器脚本放在幸福蓝天的一个文件夹中是为了便于创建和管理. asmdef文件。
可以在assets-create-assembly definition中创建. asmdef文件，并根据情况创建配置信息。
下面的三张图是我以前开发的tpns推送模块的目录结构和设置信息。 请作为参考。
在这个步骤中容易发生两个错误。
- .asmdef的平台设置发生错误-幸福蓝天下的. asmdef文件未引用运行时下的. asmdef
3 .上传和发布git
上传要发布的模块并将其推送到远程
必须在发布前上传相应的内容并将其远程推送。 我的项目正在上传和发布到主场分支。
开始发布
在以下说明中，将开发模块的名称替换为yourmodule。
因为发行时执行4行指令，所以各行指令的参数相同且不同，所以发行时不可避免地会发生上下参数不一致的错误。 在导入到package之前，可能不会发现此错误。 删除并重新提交创建的分支和标记。 我认为大多数人不喜欢这些事情。 所以，我在bat脚本中写了发布命令。 通过在发布时更改路径、名称和版本，然后双击bat脚本，可以轻松发布。
以下是bat脚本的内容
ToolName :一般为yourmodule，但为了区分一般分支，需要加上“upm-”前缀
工具版本：这里采用yourmodule-version的模式。 例如，版本1.0.1、工具版本可以是yourmodule-1.0.1
ToolAssetPath :要发布的模块的资产
根目录或是有packge.json的目录运行下面的命令，如果没有什么报错，就证明成功已经成功发布了。
::设置模块名字
SET ToolName=upm-yourmodule
::设置模块版本
SET ToolVersion=yourmodule-1.0.0
::设置模块源路径
SET ToolAssetPath=Plugin/RoneDir/Assets
::此命令会创建一个ToolName的分支，并同步ToolAssetPath下的内容
git subtree split -P %ToolAssetPath% --branch %ToolName%
:: 在ToolName分支设置标签ToolVersion节点
git tag %ToolVersion% %ToolName%
:: 推送到远端
git push origin %ToolName% %ToolVersion%
git push origin %ToolName%
pause
Tips：如果远端已经有了当前版本的标签，会发布失败。这里有两个解决方案：
- 升版本。ToolVersion与package.json的版本信息相匹配。且要大于之前的版本。 - 删除远端的标签。 source的标签栏里可以预览现有的标签，要确定删除远端已经不存在你将要发布的标签。
导入已发布package的方式
在当前项目中找到Packages/manifest.json 添加你的要引用的模块信息 确认模块名称与版本信息与发布时在package.json里的信息是一致的。
可参考下面的这段引用的设置：
"com.rone.testpackage":"http://192.168.51.222/pub/publicmodule.git#yourmodule-1.0.0",
package-lock.json
这里的内容为搬砖，点击传送门，即可跳转至出处。我觉得这有有助于理解package-lock.json的用途。
在你了解 package-lock 甚至 package.json之前，你必须了解语义版本控制。 这是npm背后的天才，是什么使它更成功。简而言之，如果你正在构建与其他应用程序接口的应用程序，你应该告知你所做的更改将如何影响第三方与你的应用程序交互的能力。这是通过语义版本控制完成的，版本由三部分组成：X，Y，Z，分别是主要版本，次要版本和补丁版本。
例如：1.2.3，主要版本1，次要版本2，补丁3。
补丁中的更改表示不会破坏任何内容的错误修复。 次要版本的更改表示不会破坏任何内容的新功能。 主要版本的更改代表了一个破坏兼容性的大变化。 如果用户不适应主要版本更改，则内容将无法正常工作。
我简单看了一下，其实常规的业务逻辑只需要：name，version，lockfileVersion这三个字段就能满足版控需求。
{
"name": "com.xxx.yourmodule",
"version": "0.0.1",
"lockfileVersion": 1
}
参考与引用