实验性 Hono auth npm 包

发布: (2025年12月11日 GMT+8 21:46)
3 min read
原文: Dev.to

Source: Dev.to

我正在构建的内容

我正在创建一个认证包,开发者可以直接把它放进自己的应用,而无需编写常见的样板代码(登录、注册、JWT、邮件验证等)。

import { initAuth } from "auth-core";

const auth = initAuth({
  DB_TYPE: "mongo",
  existingConnection: db,
  DATABASE_URL: // optional if connection doesn’t already exist
});

该包还应支持可选的路由处理器,例如:

app.route("/auth", honoAuthRoutes());

或在 Remix 中:

server.use("/auth/*", honoAuthRoutes());

简而言之:把认证当作插件

我希望这个项目的定位

  • 框架无关 – 能在 Remix、Hono、Express 等环境下使用。
  • 允许用户传入自己的数据库连接。
  • 不需要额外启动一个服务器。

我遇到的问题

  • 我不希望 npm 包直接依赖 Hono。
  • 核心认证逻辑应保持简洁,但测试和路由适配器仍需要 Hono。
  • 不确定 Hono 应该作为 peerDependency,还是采用其他方式处理。
  • 在 Remix 中使用 Hono 感觉不太自然;目前,Remix 用户必须在其 Remix 服务器内部启动一个 Hono 服务器,这似乎不太合理。
  • 需要一种干净的方式导出路由处理器,而不强制每个用户都安装所有框架。

我需要的建议

  1. 依赖结构 – 核心、可选适配器以及框架特定代码应如何组织?
  2. 在 Remix 中挂载 Hono 路由 – 这样做可以接受吗,还是有更好的方案?
  3. 整体架构 – 对于包的结构、适配器的处理以及仅按需暴露各框架所需内容,有什么建议?

欢迎提供任何技巧、建议或警示,尤其是来自以下领域的经验:

  • 认证系统
  • SDK
  • 可复用的 npm 包
  • 框架适配器

仓库

GitHub – AuthenticationSystem (server branch) – 包含可运行的 API 代码。

Back to Blog

相关文章

阅读更多 »

包管理器挖掘🪦

封面图片:패키지 매니저 파묘🪦 https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazon...

Payload 中的自定义 auth

Payload 中自定义身份验证的封面图像 https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads...

创建您的第一个 MCP 应用

TL;DR MCP 应用为对话代理和其他 MCP 客户端带来交互式 UI。 本教程展示了如何创建一个既简单又强大的应用源代码……