rm 开发与学习待办

drill page 图片层级调整实验

重新考虑静态资源文件与md文件的组织层级，不一定放在同一个文件夹下，而是在\docs\.vuepress\public\img内。因为图片id不更改

实现方式

1.1：设计 pandoc 命令生成的文件路径名。 1.2：设计全局字符串替换的规则。 1.3：设计路由自动生成的规则。设计依赖于文件夹路径的路由名称。处理拼音中文名的路由配置。查询 vdoing 的路由配置写法。未来期望情况： 2：提供公共的图片集，不做 img 图片的分仓库管理。未来再考虑自动化上传 img 图片与 md 引用路径的绝对替换。

当前实现情况

废弃。不再维护处理 drill page 的任何内容。因为 drill 文档使用了过多的静态资源图片，不适应 git 仓库提交的场景。大文件过多。经过和 drill 本人的沟通后，该文档的架构将不会改动为 md+图床的架构。

除非 drill 本人希望实现在线文档，否则不再维护，迭代此文档项目。

该文档项目的改造难点在于

静态图片资源的储存方案
多类型图表绘制
重新编制文档目录结构
设计全局路由

若不能解决上述的几个问题，那么就无法实现 docx 文档更换为 md 文档的架构转换。

使用 ts 模块化 rmmv，实现一个 cli

让 webpack 管理，运行，打包一个小规模的 demo
让这个小规模的 demo 迁移到 vue-cli 内，将配置迁移，缩减至‘vue.config.js’内
模块化 rmmv，迁移至 vue-cli 内。
标记，推广为‘rmmv-cli’
js -> ts 发布‘rmmv-ts-cli’

目前实现情况

不方便。应该树立一个新的思路来开发：

在 vite+ts 的项目内，将 mv 项目作为完全的静态渲染模板。开发插件时，将 mv 源码也作为插件开发的导入依赖。打包的时候也将部分引用到的 mv 源码一并整合。这个方案实现起来容易一些。

最终打包的时候，连同模板一起打包。后面再考虑无模板的打包。

学习代码压缩技术

代码压缩尝试 uglifyjs

目前可能暂时不需要该技术，先实现 ts 项目。先运行起来。

待学习的 jsdoc2md 技术

这个技术可以将 jsdoc 转变成 md。 https://github.com/jsdoc2md/jsdoc-to-markdown

https://github.com/jsdoc2md/jsdoc-to-markdown/blob/master/docs/API.md

以后开发出来的 ts，按照指定路径生成文档。生成后再考虑直接整合出一大堆 md 文件。最后再试着考虑使用 hope 主题自动部署该 md 文件为网站。

待研究的光追技术

YEP_GridFreeDoodads.js FilterController.js ParticleEmitter.js https://sigmasuccour.itch.io/false-server 遊戲這裡下載

以后再说吧。现在连项目都跑不起来。

错误日志本地导出的功能

在显示出错误信息时，把错误日志做 node 环境层面上的本地导出。和设计到文件的保存。试着使用之前的文件库实现该业务。

js 文件的自动检测更新，下载文件与模块异步加载

不考虑这个方案了。不应该自动更新这些依赖项。让开发者自己看情况升级，加载依赖。

如果是 node 项目的 cli，那用户自己去做 node 依赖包的升级。

如果是原生的环境，那用户自己手动替换文件。

在线运行的 rmmv

CodeSandbox，代码在线运行器，云 IDE，这个工具稍做改动，兴许就可以在线运行一个 rmmv 了。

应该去学习 github 的模板项目设置，然后直接打开一个模板项目来运行。

现在不觉得在线运行的一整个 rmmv 项目是有用的。

应当提供一个合适的最小 bug 复现模板

在线运行的是一个快速复现 bug 的 demo 模板。这样可以帮助开发者了解在业务的边缘情况下，插件的实际表现。

应当提供一个在线修改配置和运行的示例

比如，左侧表单项，右侧就是 iframe 嵌套的 rmmv 实例。直接进入到的某个 scene 场景内展示的实例。

实现场景类的指定跳转。类似于路由跳转。
实现表单数据的响应式更新。响应式的数据驱动右侧的 canvas 数据及时更新。

iframe 显示本地静态资源

有很多技术栈表明，可以使用 iframe 显示一些静态文件资源。

先试着在 VuePress 内构建自己的专属 vue 组件，让指定页面可以直接打开另外一整套的静态网站资源。

这个静态网站全部使用 vue-cli 开发。用 elementUI 做表单，这个表单最终生成可使用的代码

给仇九做一个低代码的，点击即可导出，生成代码的页面

受到和风天气页面的启发，目前先实现一个低代码生成可执行代码块的功能。想制作出一个 html，并以合适的形式部署到页面内，打包生成出最终的页面。最终的可参考效果页面：https://widget.qweather.com/create-simple

受限制的一些关注点：

仇九不使用 VuePress，尽可能不要更换其文件夹目录以实现生产环境静态资源的部署
仇九的插件是国际化的，静态文件资源要实现基本的 i18n 功能。需要使用 vue-i18n 库。

目前想到的一些技术方案如下：

VuePress + elementUI

在 VuePress 页面内，使用 elementUI，开发自定义组件。进而实现一系列的功能。关键在于如何让自定义的 vue 可以被 VuePress 识别并打包。还要实现在生产环境下不出现错误。

可参考的内容： https://www.yuque.com/yihui123/fe/vuepress https://github.com/Lee-Tanghui/vuepress-element-doc https://github.com/search?q=vuepress+elementui

VuePress + iframe

在 VuePress 内，直接使用 iframe 打开位于静态文件资源夹的页面。直接在 md 内使用 iframe，导入静态文件资源即可使用相关的功能。可能的缺点是大小不够合适，显示效果不佳。

静态文件直接访问路由

利用静态文件的特性，直接把生成的生产环境级别文件，复制粘贴到 VuePress 的静态资源文件夹内。其实现原理和上一条完全相同。但是差别在于访问的形式，访问的资源不是 webpack 导入的静态模块，而是利用服务器静态文件资源访问的性质来跳转页面，进而使用后续功能。

这会带来一个问题，VuePress 可以承载静态文件资源，那么作为开发版本的 vue-cli 需要和 VuePress 项目合并在一起么？怎么让一个 vue-cli 项目变成 VuePress 的子项目？并且实现打包出来的文件生成到.vuepress/public/target 目录内？

直接定义一个特殊的文件夹来存储网页

考虑到仇九网站的文件夹整理层级，这里的方案是构建一个单独的文件夹，借助路由跳转的方案，直接访问到产品界面。其中 vue-cli 项目由阮中楠自己保管管理。

暂定的协作流程：

阮中楠自己开辟一个新的仓库，用 vue-cli 开发一个页面。并自主部署到相应的 gitee page 页面内。
与仇九共同检查，逐步优化，迭代升级产品。
将产品打包，迁移到仇九的仓库内，当做是生产环境下的部署。
仇九在文档内提供跳转链接，以生产环境链接或相对路径的方式跳转到产品页面内。

用 gulp 来实现 jsdoc 相关的自动化任务配置

现在已经学会用 jsdoc 生成文档了。也学会使用外部依赖包，生成 tsd 类型文件。现在希望用 gulp 同时执行两个命令。一次性生成文档和类型文件。

https://github.com/deshaw/gulp-jsdoc3#usage 我需要学习一下 gulp。让 gulp 去完成一些命令。我希望构建出两项 task 任务 1：执行 jsdoc 打包任务，使用特定的 better-docs 模板。生成出可阅读的文档。 2：执行 jsdoc 打包任务，使用特定的 tsd-jsdoc 模板。生成出.d.ts 文件。

进度

目前可以完成命令执行，但是效果很糟糕。目前无法让 gulp-jsdoc3 实现生成 tsd 文件

文件导出格式

现在考虑拆分出更加细致准确的 jsdoc 配置，但是发现这个 jsdoc 配置不能使用 ES6 的模块语法来导出。

角度判断的算法实现

实现业务，实现角度的判断功能。根据 x y 的坐标点，判断出目标与本坐标点的方向

联系人

QQ:1090325382

完成后，在 drill 群内联系此人，并将代码提供给他。

大致开发思路

观察 tan 和 arctan 函数，观察三角函数的图像关系。最后使用判断 arctan 反正切函数的 y 值范围，来判断出方位。

1：定义一类插件，busi1.js、busi2.js 插件，称呼为业务插件。业务插件只提供插件注释。不写任何 js 逻辑。 2：定义另一类插件，core.js 核心插件。 2.1：核心插件会直接获取插件参数数组。 2.2：核心插件会做接口请求，获取唯一的，打包好的，合成的一份 js 文件。这个文件会自动更新。用户获取的文件均来自服务器。 2.3：核心插件会手动插入 script 标签，保证能够覆写覆盖源码。 2.4：核心插件会自动执行完全部的业务逻辑，根据是否有插件参数来做出相应。 2.5：核心插件本身不提供插件注释。

尝试使用浏览器原生的 api 实现文件保存

初衷

希望使用这些东西

技术实现关键词： vue 下载文件保存到指定文件夹

参考资料： https://blog.csdn.net/chenacxz/article/details/125858998 https://blog.csdn.net/qq_38157825/article/details/114630135

rmmv 使用 elementUI 的弹框组件

经过测验，得出结论：不应该直接在原生的 H5 内，使用纯 js 来封装使用组件库。直接使用渲染函数的写法非常坐牢。

目前暂定的思路如下：

1：用 webpack、rollup、或者是 vite 来构建开发环境，在开发环境内使用全套的组件库。可以试着使用最新潮的技术，如 vite + ts + elementUI plus 的开发流。 vite 打包的东西可能无法有效指定文件格式，值得注意。

2：打包成单纯的，iife 形式 js 文件。文件必须是一份单独的 js 文件。不能拆分成更多的子文件，必须只有一份文件。文件本身不经过压缩和混淆，全部开源。保证用户的开发环境可以有效的调试错误。文件本身要提供 babel，版本默认锁死在 es5，不提供任何高版本的 js 语法，以防出现用户的 nw.js 识别错误的情况。

3：在 rmmv 内适配。适配时，注意样式内容的获取方式。可能使用 cdn 插入标签的方式来生硬的加载外部的 css 依赖。

拓展学习： p2p

p2p 去了解，然后就到了 webp2p，然后到了 webtrc，到了 hsl.js，然后到了加密货币，然后到了区块链

用 webpack 实现自定义打包流程

1：构建一个 github 项目： rmmv-webpack-sample 1.1 https://codesandbox.io/s/ 导入项目，并在线运行项目并实现分享效果

2： webpack node https://webpack.docschina.org/api/node/

针对 rmmv 的插件代码，自定义 webpack 的打包行为可能是不错的方案。

nw 本身提供的代码压缩功能

如下图提供的例子所示：

使用 arraybuffer 类型来请求 js 文件，并用此文件来加载 js 文件作为项目的依赖。试一下这种全新的方式来导入 rmmv 插件。

rollup 开发环境

考虑用 rollup 搭建开发环境。要不然不方便实现测试。打包出来的产品没有合适的位置做测试。

还需要先实现一个尽可能小的 rmmv 源码小例子。越小越好。静态资源越少越好。

期望的 drill 插件架构

期望的 drill 插件是这样架构： @drill-up/core @drill-up/error-report @drill-up/auto-update @drill-up/params-verify @drill-up/plugins-recommend-config @drill-up/preset-env @types/drill-up

项目根目录下存在这样的一个中央配置文件drill-up.config.js。

用户通过这样的方式安装钻头的插件：

pnpm i -P @drill-up/core @drill-up/preset-env

用户的插件总数不应该再臃肿到200+，而是尽可能减少用户插件列表的数量。

插件列表内安装的.js文件应该重新定位，定位成桥接 rm 和代码之间的参数接口。对外仅提供参数接口，实际的业务一律在第三方依赖包内实现。

该架构的实现方式

先学会 monorepo 单仓架构，再学会 pnpm 的工作区配置，最后再考虑发包。

用 unpkg 实现代码分发

Unpkg 方案可以用于实现钻头代码的 cdn 获取。

drill 的代码可以实现生成一个巨大单文件，然后发布为 npm。

如果用户有能力自己搭建 node 环境，就自己 pnpm i -P @drill-up/code 依赖。
如果用户就是使用原生的 H5 环境，就自己使用 script 导入 cdn 链接。

unpkg 方案比之前的 github.raw 方案更加好：

url 更加简短
锁定版本号
也可以实现自动更新

RPGMaker md 文档抄袭与重新部署

在项目 https://github.com/futokoro/RPGMaker 内。实现简单的 docs 迁移。

试着使用二级域名的方式，照抄别人的 md 内容，实现一次简单的部署。

思路一

摘抄别人的 md。
部署项目。
链接到本项目。

试着使用 git 子项目的方式，fork 别人的项目。直接拿到相关的 md 页面，然后直接本页面内实现一次部署，这样也可以实现爬虫的查询，效率更高一些。

思路二

fork 别人的项目直接嵌套在指定的.vuepress 目录下。
用 github 工作流的方式，加上 vercel 配置，实现部署到指定子域名内。
部署到子域名时，再多配置一个 algolia 爬虫。
跳转外链，直接进入到指定格式生成的网站内。完成。

思路三

用 git 子模块的方式，模块化的拉取对方的 md 文件。

疑惑？提交到仓库的东西不包含别人子模块的内容，自动部署时，应该让 vercel 先实现拉取子模块的内容，然后再开始执行构建命令；
试着在 package.json 内配置命令。简单的组装几个命令即可。

将遇到的 rmmv rmmz 的 ts 内容整理成专门的页面

QQ 群的 764495276 群主，需要对接跟 rm+ts 的技术栈内容。

对模块化改造 rmmv 代码的思考，以及一些可能的实践方案

至少需要去考虑：

语言选型 js ES6+ 还是 TS4.9+ ？

模块化工具是传统的 webpack，还是 vite，亦或是 esbuild，rollup？

静态文件资源处理压根就不管。还是自己想办法在代码内写死这样的静态文件导入？

最终我想的是，应该提供一个 node 开发环境版本的 rmmv，其语法结构和框架选型都是最新版的。有这样的要求：

1 打包结果不能混淆源码，仍旧保留源码内容，便于旧版本插件覆盖源码。 2 我们自己编写的插件应该有能力实现独立的打包/导出功能，导出为 ESM，或者是传统的 IIFE。

现在的开发模式是不会去考虑源码和插件的关系的。我提供了模块，但是源码本身就很独立，源码本身怎么去知道要导入谁的代码呢？

我能想到的就三种实践方式