CFPAOrg
仓库杂项/1.20支持 TODO List
相比于#2821 而言，这次的时间应该没那么紧张。但是先列出来吧。 其中有一些可能不是马上就需要的，但是也先列出来吧。
目前，1.20工具链已经完成，且理论上已经开始分发了。余下的大多是些远期规划。
- [x] 确定1.20（或更高版本）的支持计划
- 目前确定为1.20与1.20-fabric分开支持
- [x] ~建立1.20的预备分支，在工作完成后合并 -- dovisutu:1.20-preps 基于3288的分支，在合并后会手动rebase~
文件结构/工作流程
- [x] 正确书写文件层级，以及Packer的配置文件
- [x] https://github.com/CFPAOrg/Minecraft-Mod-Language-Package/issues/3182#issuecomment-1659397334 提供下载源的标记
- Github Actions 相关内容
- 优化结构： - 预备分支中 未测试
- [x] 采用matrix，减少配置的复制粘贴
- [x] 用缓存减少构造次数
- Uploader似乎会生成一大堆dll，光搬个exe跑不了......在解决这个问题前，只有每次上传都构造一次了。
- Packer倒只有两个文件，没多大问题。
- [x] pr-packer只打包更改模组（需要Packer支持）
也可以缩短传artifact的时长
- [x] 分发相关：Packer、PR-Packer - 预备分支中
- [x] 校验相关：Labeler、~Path-Checker~（可能可以合并）
- 路径校验在Bot和Packer中分别集成了一份，应该可以避免无效资源包流出。
- 标签工作有部分集成到了CFPABot，但有的仍需修改Action。
- 优化结构： - 预备分支中 未测试
- [x] bot支持
- [x] i18n模组版本支持
- [ ] （远期）可以考虑重新开始爬取模组，前提是准备高效的办法统揽翻译工作（现在这种手工做法显然不行）
Packer TODO
dovisutu:packer-rework
- [x] #3669 更好地选取无语言标记的文件
- [x] 支持传参模组表，仅选取这些模组打包
- [x] #3527 打包器支持非平铺的语言文件（至少不要崩溃） - ~啊c#好像没有Union...~
- [x] 集成在打包器中的路径校验，对无效路径现场抛异常，防止资源包崩溃
- ~#3604 应该实现了。但是还没实测~
- ~按照预计的打包流程修改，我好像没办法在一堆查询表达式里面塞个异常......~
- 解决办法：强行塞方法调用
- [x] 打包器部分流程会重复执行，现有代码不够健壮，导致处理非文本文件时会崩溃。
- 之前以为没什么，但是 #3226 的修复暴露了这个问题。
- 推测可能是IEnumerable有时会反复遍历，这也是没办法的。
- [x] #3635 workaround；仍然需要研究重复执行的原因，以免再度事发。
- [x] 预计解决：直接干掉“不够健壮的部分”，在检索里不产生副作用
- [x] 检索部分重写：真正地使用Linq
- [ ] 检索逻辑独立成库，以便其他工具链检索语言文件（如cfpaBot、各种统计工具）
分发流程
这里与1.20没有直接关系，但是也是最近要做的。
- 增量更新
- [ ] 自动向服务器上传差异文件 - Uploader；ETA未知
- [ ] 服务端提供API（？）
- 按需打包（部分打包）
- [ ] 确认用于判断现有模组的方案：modid，或是其他潜在的方案
- [ ] 如果使用modid，信息区分度是否足以判定需要哪组资源？
- [ ] 确认时序：这种资源包在哪一步打？
- 个人的意见是直接在第一步（Packer）生成，因为这里有完整的模组标识符->命名空间表
- 实现部分
- Packer：需要支持指定模组（见Packer ToDo）；模组表为“模组标识符”
- （未知组件）维护modid->标识符的映射
- i18nmod：合适地读取modid表
- [ ] 确认用于判断现有模组的方案：modid，或是其他潜在的方案
资源包
- [x] #2721 - #3226 - #3288 ：字体修复全面更新
- 由于1.20去除了对legacy_unicode加载器的支持，这一点是必需的。
- [x] ~（可能需要）~ 修改Packer，以将字符替换做成版本特定
- 这个就做在3288里面了。
- 模组收录问题
- [ ] 是否需要推行基于现行packer-policy的适配方案？
- [x] 优化现有方案
如：加载过程分解成类似字体描述文件的样子
- [x] 优化现有方案
- [ ] 是否需要与现有的资源包合并机制协同？
- [ ] 是否需要推行基于现行packer-policy的适配方案？
- [x] 对“组合式”的语言文件，引入简化格式（需Packer支持）
- 目前设想：“模板”段和“参数”段分别存储，打包时自动生成文件；“模板”段内包含格式符，可以填入内容
- [ ] 全面清查
cp 1.16 to 1.18 - [x] #4592
文档相关
- [ ] #3178
- [x] #2857 - #3618 参考文档更新
合理的TODO列表
- [x] 确定合适的实现方式（projects？但是Github Mobile看不到）
Packer系列单列表 （本来想列自己那边的，结果issue创不上了...）
Packer ToDo/Refact
- Meta - 局域配置文件 - policy改写
- Models
- 文件模型：基础接口
IResourceProvider，上面实现RawFile，TextFile，McMetaFile(?)，TermMappingProvider<TValue> - 考量：是否要实现成Immutable？
设计如此；需要考察性能
实测表明运行速度慢了一些，但是10s肯定能跑完（像116这种大的可能六七秒） - 考量：两种LanguageFile应该继承TextFile存储原文，还是一律序列化成字典？
全部转字典，因为CompositionProvider没“原文” - 考量：LanguageFile系列如何“优雅”地实现key-value字典？因为value表目前是Lang为string，json可能需要用JsonElement才能避免一堆奇怪的文件
目前的想法是自创一个ITermDictionary<TValue>暴露公用方法，强行实现Union - 暴露方法/字段： -[async]Task AddToArchive(ZipArchive archive); // 加入文件-IResourceProvider Append(IResourceProvider incoming, bool overrideExisting = false); // 合并文件
或者说，~要不写成重载运算符operator+得了...~ 我感觉接口没有重载运算符吧 -IResourceProvider Replace[Content, Destination](string searchPattern, string replacement // 替换组件，将支持Regex - Lib.cs（检索组件a）- 正统的Linq检索语法
- 生成的应当是
IEnumerable<IResourceProvider>；中间的Mod和Asset信息应当可用typed Tuple？ -groupby + Accumlate // 排重空间-Where(_ => _ in acceptedModsList ?? true) // 传参支持 - Extensions/DirectoryExtension.cs（检索组件b - policy） - 将加载方案改成依次执行可覆盖 - 仍然使用Aggregate；多播没法在一个对象上执行...
- Config
- 新增项：forceInclude，asNonText，？？
对 packer 的建议：可以再重新设计 Packer 的打包逻辑，不然一到后期支持版本多起来以及模组数量多起来了一遍遍过确实是太过于浪费时间了
不然一到后期支持版本多起来了一遍遍过确实是太过于浪费时间了
如果我没写错的话，现在Packer和PR-Packer好像都是只打包被更改的版本吧 （还是我没理解清楚？）
如果我没写错的话，现在Packer和PR-Packer好像都是只打包被更改的版本吧 （还是我没理解清楚？）
我的表达问题，实则想表达的是想让PR-packer打包的文件中只包含更改的一个或几个模组，不然 Upload 这一条耗得时间就太长了。（例：若PR中同时更改了1.16 1.18两个版本的汉化文件，一整个流程走下来得六七分钟，过于耗费时间了。
想让PR-packer打包的文件中只包含更改的一个或几个模组
~巧了，这个我也做了~
目前逻辑是，如果改了打包器/配置，pr-packer会打包某版本的所有文件；否则，只打包被更改的模组。（因为不好判断配置等会改变哪些文件，只有全部打包。） 然后3875“恰好”更改了打包器和配置，这就提现不出来了。
packer肯定还是要全部打包的。