🚀 iGit - 智能 Git 工作流助手

💡 项目简介

在日常开发中，Git 工作流是每个开发者必不可少的一部分。然而，标准化提交信息、执行代码检查、确保代码质量等工作往往需要耗费大量的时间和精力。iGit 正是为解决这些问题而生的智能 Git 工作流助手，它能够帮助你实现更智能、更高效的 Git 工作流程。

✨ 核心特性

• 🤖 AI 驱动的提交信息 - 自动生成符合约定式提交规范的提交信息，让你的提交历史更清晰、更专业
• 🎯 智能 Git Hooks - 提供一系列开箱即用的 Git Hooks，帮助你规范代码提交流程
• 🎈 简单易用 - 通过简单的命令行工具，轻松集成到你的项目中
• ⚙️ 高度可配置 - 提供灵活的配置选项，满足不同项目的需求

🛠️ 技术栈

• Node.js
• OpenAI API
• Git Hooks
• YAML 配置

📝 安装与使用

1. 安装依赖

1
2
3
4
5
6
7
8

# 使用 npm
npm install -D @doremijs/igit-cli

# 使用 yarn
yarn add -D @doremijs/igit-cli

# 使用 pnpm
pnpm add -D @doremijs/igit-cli

🚀 fe-conf - 配置生成器

前端喜欢造轮子，也喜欢搞各种工程化，项目中经常配置了各种工程化工具，而这些工具要么是xxx-cli初始化生成，要么自己手动配置，每次针对项目可能还要做一些配置调整，而且看着package.json里一堆依赖又很碍眼，而fe-config就是用来解决这个问题的。

fe-conf由2个项目共同组成（后续可以合并？），一个配置生成器config-generator，一个默认配置好的配置集合doremi-config。2者配合使用就可以完成项目工程化的配置。当然fe-conf生成的是默认配置，你也可以按照自己的需求进行调整。

🛠️ OpenAPI Generator - API 客户端生成

💡 项目背景

在现代前端开发中，与后端 API 的交互是不可或缺的。然而，手动编写 API 调用客户端不仅耗时，还容易引入类型和调用错误。@doremijs/o2t 正是为了解决这一痛点而生的 OpenAPI 客户端生成工具（简称o2t）。

✨ 核心特性

• 🚀 全自动生成类型安全的 TypeScript API 客户端
• 🎯 简单配置，一键生成
• 📦 灵活的拦截器和错误处理机制
• 🔒 支持 OpenAPI/Swagger 规范（v2 和 v3）

🛠️ 技术栈

• TypeScript
• Fetch API
• OpenAPI/Swagger 规范

🚀 图片压缩工具 - 本地的极速图片压缩工具

在前端开发过程中，图片资源的优化一直是一个重要的环节。过大的图片文件会影响网站的加载速度和用户体验，而手动压缩图片又比较繁琐。市面上虽然有很多图片压缩工具，但大多数要么是在线服务需要上传下载，要么是收费软件。为了解决这个问题，我开发了一个简单易用的本地图片压缩工具。

这是一个使用 Electron 和 Sharp 开发的图片压缩应用程序，专为前端开发者/UI设计师使用，用于批量压缩图片。它模仿了 ImageOptim 的使用体验，但增加了一些个性化的功能。

原本我是打算使用 Tauri 开发的，但是在处理 libvips 和 pngquant 的动态、静态编译时遇到了一些技术难题，所以最终选择了更成熟的 Electron 框架。

🖼️ 预览

🚀 文汇 - 文档管理平台

在企业应用开发过程中，我们经常需要提供各种合规文档，比如隐私政策、用户协议、免责声明等，这些文档通常需要定期更新，以确保它们符合最新的法律法规和公司政策。当我们在小程序中集成这些文档时，通常需要手动更新，非常麻烦，而且需要重新审核，同时网页端应用可能也要展示这些文档，所以一个可以同时服务多端的文档管理工具就比较重要。这也是我创建文汇(wenhui)项目的初衷。

项目的整体框架我是直接从之前的sync-gitea-server项目中继续迭代过来的，所以在开发和配置上会有很多相似的地方。

后来业务上需要使用本服务多项目较少，所以没有继续迭代。未来可扩展的一些方向有文档复制、文档搜索、文档统计等等，也可以做成商业化产品。

文汇是一个文档管理平台，旨在帮助用户更高效地管理和利用文档资源。它提供了一个集中存储、组织和检索文档的系统，同时支持文档的协作和共享。

我为项目创建的 slogan 是：

「汇聚文档，赋能应用」 (Where docs meet apps)

🚀 sync-gitea-server - 代码仓库同步工具

我们开发时的代码仓库一般都放在阿里云效上，刚开始我们尝试使用云效自带的流水线来实践CI/CD流程，但是云效有很多限制，甚至绑定了阿里云的体系，导致很多场景没法实现自动化，于是我们将CI/CD流程迁移到内网实现。我们对比了一些开源方案，最终选择Gitea作为代码同步仓库，并使用Gitea自带的Actions来实现CI/CD流程。Gitea的几个特点正好符合我们的需求：

• 轻量级，资源消耗少，部署简单
• 支持兼容Github Actions的语法来实施CI/CD流程，可以直接服用现有的大量Actions能力
• 支持LDAP认证，可以直接使用内网的用户体系

唯一的问题是无法实现自动、实时地从云效同步代码到Gitea，于是我开发了sync-gitea-server项目，用于实现自动、实时地从云效同步代码到Gitea。项目的整体框架我是直接从之前的fake-sms项目中复制过来的，所以代码结构上会有很多相似的地方。

sync-gitea-server是一个用于同步代码仓库的 webhook 服务器。当上游代码仓库（如云效）发生变更时，它会向此服务器发送webhook 事件，服务器随后调用Gitea API 来同步这些变更。

通过这个服务器，我们可以实现代码仓库的自动、实时同步，无需人工干预。目前该项目已经在我们内网运行，新项目都已经接入，非常稳定。

🖼️ 预览

🚀 fake-sms - 模拟短信服务器

这是一个搁置了的项目，原本是想要在多项目中使用，但是后来没有项目可应用，就暂时搁置了，但是我觉得它还是很有价值的。项目整体流程没有得到完全的测试，可供参考，请不要在生产环境使用。

fake-sms是一个用于测试基于短信的应用程序的模拟短信服务器，在项目开发时使用它来代替真实的短信发送，可以减少企业在测试环境中的成本。

默认情况下，fake-sms 与 Casdoor go-sms-sender 兼容。

🌐 在线体验: https://fake-sms.erguotou.me （家中服务器，暂时关闭）

🖼️ 预览

🚀 rust-http-server - 极简HTTP服务器

多年没有更新博客了，不过工作期间倒是在做项目中提炼了一些项目和工具，现在开始整理下这些项目并记录下。

做前端的或许都知道http-server或者serve模块，它们都是用来快速启动一个http服务，方便本地开发调试和提供简单的文件服务。我也想复现一个，并学习下Rust语言，于是就开始了入坑之旅。

为什么用Rust再造一个HTTP服务器？

🌟 项目背景：现有工具的痛点

作为前端开发者，你是否厌倦了这些场景？

• 每个项目都需要配置一次nginx
• 调试nginx配置时频繁修改.conf文件
• 启用压缩可能需要安装额外的nginx模块
• 代理配置繁琐，SPA 项目每次都需要try_files
• 想快速实现文件上传却要额外搭建服务

这就是我开发Rust HTTP Server的初衷 - 一个专为现代前端部署优化的全能服务器，在单二进制文件中集成了你需要的一切功能！