前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载导读本文基于 Dillinger 仓库内的任务跟踪文档 tasks/todo.md完整还原了该项目从 Angular 版迁移到嵌套 Next.js worktree 后的最后一公里如何把可执行的发布范围冻结下来、用 Vitest Playwright 搭建自动化验证基础设施、逐项补齐 markdown 渲染 / 导入导出 / 图片处理 / OAuth 一致性等 parity 缺口并最终跑通 lint、typecheck、单测、构建、浏览器 E2E 的发布门禁随后推进 Vercel 上线与 PDF 导出在 serverless 环境下的修复。读完本文你将掌握一套以自动化测试与浏览器 E2E 作为本地证据、以稳定 beta 分支 固定回调地址作为上线策略的 Next.js 应用交付方法论并了解 Dillinger 各 OAuth 服务回调端点、环境变量与 PDF 服务端渲染的底层实现。一、背景嵌套 Next.js worktree 与发布范围冻结1.1 迁移的实际代码载体Dillinger 的 Next.js 迁移并非发生在仓库根目录而是发生在一个被 Git 忽略的嵌套 worktree中/Users/joemccann/dev/vercel/dillinger/.worktrees/nextjs-migration/next-app对应本仓库根目录。tasks/lessons.md 记录了两条重要经验当用户提到 the worktree 时应先检查.worktrees/下的嵌套 Git worktree而不是默认根 checkout 就是唯一相关代码库当.worktrees/被 gitignore 时嵌套 worktree 可能仍是活跃的实现分支即使它们不出现在根目录的git diff或git status中。这意味着迁移工作与主仓库演进并行发布门禁、测试证据都针对该 worktree 内的next-app目录其结构与本仓库根目录一致例如 package.json、app/api、lib、tests 等。1.2 冻结可执行的发布范围T1todo.md 将整个收尾工作组织成一张带依赖关系的任务图T1冻结嵌套 Next.js worktree 的可执行发布范围并把完工报告翻译成实施计划depends_on: []T2在 worktree 中搭建单元/集成覆盖率与浏览器 E2E 的自动化验证基础设施depends_on: [T1]T3恢复冻结发布范围所需的 markdown、preview、导入导出、编辑器状态 paritydepends_on: [T2]T4完成图片处理、服务/OAuth 一致性以及文档清理depends_on: [T2, T3]T5运行发布门禁测试、typecheck、lint、build 与浏览器 UI/UX 验证depends_on: [T3, T4]。冻结范围的定义非常具体把当前 Next.js 应用提升到它自己的 README 与迁移文档所声明的行为水平并用自动化测试与浏览器 E2E 作为本地证明。初始基线是worktree 已经能通过npx tsc --noEmit、npm run lint、npm run build但没有任何测试基础设施且在 markdown 渲染、导入导出行为、图片处理、设置项接线与集成一致性上存在已知 parity 缺口。二、搭建自动化验证基础设施T22.1 验证栈选型Vitest Playwrighttodo.md 明确记录了最终落地组合Vitest单元/集成 Playwright浏览器 E2E外加生产模式的verify脚本。这套基础设施直接固化在 package.json 的 scripts 中scripts: { dev: next dev, build: next build, start: next start, start:test: next start -H 127.0.0.1 -p 3005, lint: next lint, typecheck: tsc --noEmit, test: npm run test:unit npm run test:e2e, test:unit: vitest run, test:watch: vitest, test:e2e: npm run build playwright test, test:e2e:headed: npm run build playwright test --headed, verify: npm run lint npm run typecheck npm run test:unit npm run test:e2e }其中verify是发布门禁的总入口串行执行 lint → typecheck → 单测 →build Playwright E2E与 todo.md 中 T5 的门禁定义完全对应。2.2 Vitest 配置要点vitest.config.ts 的关键配置默认环境为jsdom配合 vitest.setup.ts 完成 React 组件测试所需的 DOM 环境通过vite-tsconfig-paths支持/路径别名与 Next.js 的 tsconfig 保持一致include: [tests/**/*.test.ts, tests/**/*.test.tsx]统一收集测试restoreMocks/clearMocks保证用例间状态隔离。仓库内已落地一批单元测试tests/lib/cache、document、export、import、markdown、utils、tests/store/store.test.ts、tests/hooks/useGitHub、useImageUpload以及tests/components/navbar、settings-modal、document-title 等覆盖了文档模型、markdown 渲染、导入导出、存储与核心 UI 组件。2.3 Playwright E2E 配置与浏览器证据playwright.config.ts 中值得注意的细节固定使用http://127.0.0.1:3005作为 baseURLwebServer以npx next dev -H 127.0.0.1 -p 3005启动注释明确说明由于生产构建存在既有的 prerender 错误E2E 走 dev 模式单 Chromium 项目Desktop Chrometrace: on-first-retry、失败截图、video: retain-on-failure便于排查超时与断言超时分别为 45s / 5s。E2E 用例覆盖了 todo.md Browser proof 段落列出的全部场景例如 tests/e2e/import-export.spec.ts 验证本地 markdown 导入后新建文档标题Imported.md出现在文档列表预览渲染# Imported且原有文档Playwright Smoke.md保留在侧栏——这正是 T3导入新建文档而非覆盖当前文档的回归证据本地 HTML 导入经转换后同样新建文档标题Imported.html预览渲染HTML Imported图片插入通过image-import-input上传 PNG 后预览区出现img导出语义普通 HTML 下载文件不含styleStyled HTML 下载文件含style与 KaTeX 样式引用且文件名统一规范化为Imported.html。tests/e2e/editor.spec.ts 则覆盖文档新建/重命名含 Escape 取消、切换、删除确认、预览开关、Zen 模式CmdShiftZ进入、Escape 退出、设置弹窗夜间模式、tabSize 持久化、markdown 各元素渲染准确性、字数统计与侧栏开关。tests/e2e/smoke.spec.ts 验证编辑器外壳与核心控件侧栏开关、#preview、字数/字符数、设置弹窗、夜间模式开关。一个值得借鉴的测试技巧E2E 通过page.addInitScript在页面加载前向localStorage写入files、currentDocument、profileV3来播种应用状态从而避免依赖 Monaco 编辑器的复杂交互专注验证业务行为。三、恢复功能 parityT3markdown、预览、导入导出与编辑器状态3.1 Markdown 渲染栈从 package.json 的依赖与 docs/plans/2026-01-19-nextjs-migration-design.md 的设计记录可知渲染以markdown-it为核心启用html: true、linkify: true、typographer: true并通过插件扩展 abbr、checkbox、deflist、footnote、ins、mark、sub、sup、toc配合 highlight.js代码高亮与 KaTeX数学公式。渲染管线封装在 lib/markdown.ts 中预览组件 components/preview/MarkdownPreview.tsx 消费该管线E2E 中对标题、加粗、斜体、有序/无序列表、引用、行内代码、链接的断言即是其行为契约。3.2 导入HTML 转 Markdown 服务端路由todo.md 提到的 HTML import conversion route 落地于 app/api/import/html-to-markdown/route.ts其回归测试在 tests/routes/import-html-to-markdown.route.test.ts。配套的turndown依赖package.json负责 HTML → Markdown 转换而breakdancepackage.json同样是转换链的一部分。关键行为有 E2E 证据本地/云端导入一律创建新文档绝不覆盖当前正在编辑的文档——这是 parity 修复中最重要的用户可见行为之一。3.3 导出普通 HTML 与 Styled HTML 的明确语义todo.md 强调 explicit plain/styled HTML export semantics 与 export filename normalization。其实现证据在 lib/export.tsrenderHtmlDocument({ title, html, styled })styled为真时注入STYLED_EXPORT_CSS包含 Georgia 衬线正文、#35D7BB链接色、代码块底色、表格边框、KaTeX 样式等为假时输出纯净 HTMLgetExportFilename(title, extension)先经sanitizeDownloadFilename清洗、再用replaceExtension统一扩展名保证导出文件名规范、安全title为空时回退到document。前端导出菜单HTML 与 Styled HTML 两个菜单项与 tests/routes/export-html.route.test.ts、tests/routes/export-markdown.route.test.ts 共同锁定该语义。3.4 编辑器状态编辑器采用 Monacomonaco-editor/react支持 Vim/Emacs 键位monaco-vim、monaco-emacs文档状态由 Zustand storestores/store.ts统一管理profileV3存储设置项。E2E 中更新内容后预览同步刷新与设置持久化即是对编辑器状态 parity 的回归验证。四、图片处理、OAuth 一致性与文档清理T44.1 图片插入与上传todo.md 记录的 image insertion UI upload coverage 体现在前端图片选择输入E2E 中的image-import-input与useImageUpload钩子hooks/useImageUpload.ts服务端上传路由 app/api/upload/image/route.ts 及其测试 tests/routes/upload-image.route.test.tsE2E 以 1×1 PNG 验证预览区出现img。4.2 OAuth Base URL 统一归一化T4 的另一关键点是 OAuth base URL normalization across service routes。所有服务的 OAuth 路由都通过统一的 lib/env.ts 获取应用地址const DEFAULT_APP_URL http://localhost:3000; export function getAppUrl() { return ( process.env.NEXT_PUBLIC_APP_URL || process.env.NEXT_PUBLIC_BASE_URL || DEFAULT_APP_URL ).replace(/\/$/, ); }即NEXT_PUBLIC_APP_URL→NEXT_PUBLIC_BASE_URL→http://localhost:3000的三级回退并统一去除末尾斜杠。每个服务在此之上拼接自己的回调地址例如 GitHubapp/api/github/oauth/route.tsconst redirectUri ${baseUrl}/api/github/callback; const scope repo,user; const authUrl new URL(https://github.com/login/oauth/authorize); authUrl.searchParams.set(client_id, clientId); authUrl.searchParams.set(redirect_uri, redirectUri); authUrl.searchParams.set(scope, scope);Bitbucketapp/api/bitbucket/oauth/route.ts则用URLSearchParams声明response_type: code与scope: account repository。这一归一化保证了本地、beta、生产三种环境下回调地址只会随NEXT_PUBLIC_APP_URL变化而不会因代码分支出现漂移——这正是后续 Vercel 上线能只改环境变量不改代码的前提。4.3 文档清理该阶段还包含对 README、迁移文档与 docs/PRODUCTION-OAUTH-CHECKLIST.md 的同步清理后者沉淀了每个 OAuth 提供方的生产回调地址格式、环境变量清单与部署后测试清单见下文第七节。五、发布门禁T5npm run verifytodo.md 给出最终门禁结果npm run verify通过即依次跑通npm run lintNext.js ESLintnpm run typechecktsc --noEmitnpm run test:unitVitest 全量单元/集成测试npm run buildNext.js 生产构建生产服务器上的playwright test浏览器 E2E。Playwright 的浏览器证据链todo.md 原文归纳播种应用 → 验证外壳控件、计数、设置 → 本地 markdown 导入 → 本地 HTML 导入转换 → 图片插入 → 旧式文档保留 → 普通/样式化 HTML 下载行为全部针对生产服务器完成。这套本地证明 浏览器证明的组合是冻结范围从声明走向可验证的关键。六、生产交接报告与 Vercel 上线6.1 交接报告T1–T3 审计了 worktree 变更、验证状态与部署文档后生成了 HTML 交接报告todo.md 记录的产物位于 worktree 的docs/reports/下本仓库根目录可参考的同类报告是 docs/reports/2026-03-10-refactor-finish-report.html。报告要点明确迁移真实应用是嵌套 worktree 下的next-app而非根 checkout汇总已实现的 diff、本地验证证据、剩余 Vercel 与域名设置、各 Provider 所需环境变量以及上线前必须跟进的 OAuth 回调/API 事项上线建议稳定 beta 分支映射到beta.dillinger.io理由是 OAuth Provider 需要固定的回调 URL而不是临时的 Preview 部署 URL。6.2 Vercel 上线七步走含验证闸门todo.md 的 Vercel Rollout 段把上线拆成 7 个带依赖的任务每一步都在改变 Git/Vercel 状态前先记录验证闸门审计worktree、既有 Vercel 项目/域名状态、本地密钥来源记录部署计划明确验证闸门提交并推送分支feature/nextjs-migration推送到origin提交814f2098c6db2c3d34bd4e9606784ea552725281并验证远端分支 SHA 一致配置 Vercel 项目保持根目录为next-app并把框架预设从过时的 Angular 设置修正为正确的Next.js本地通过.vercel/project.json关联到joe-mccanns-projects/dillinger项目beta 域名映射与环境变量给dillinger项目添加beta.dillinger.iogitBranchfeature/nextjs-migration并在Preview (feature/nextjs-migration)设NEXT_PUBLIC_APP_URLhttps://beta.dillinger.io、Production设NEXT_PUBLIC_APP_URLhttps://dillinger.io用vercel env ls核对两条记录Provider 密钥从.env.local装载并应用到 Preview 与 Production 两组环境共 12 个变量GitHub、Dropbox、Google Drive、OneDrive、Bitbucket、Medium 的 client ID/secret 六对连同NEXT_PUBLIC_APP_URL一起在两个目标环境核对部署验证与复盘重新部署 Preview 后确认beta.dillinger.io别名指向https://dillinger-nzbzrjava-joe-mccanns-projects.vercel.app。6.3 上线中暴露的阻塞点Preview 部署保护验证环节立刻暴露了最高优先级阻塞curl -I https://beta.dillinger.io返回HTTP/2 401Vercel Authentication。beta 域名已生效且映射正确但在 Preview 部署保护被放宽/绕过之前公网 beta 访问与 OAuth 回调测试都会被 401 挡住。todo.md 同时将其列为部署后最高风险的托管检查项之一第三方 OAuth 回调跳回/api/*/callback时任何 beta 部署保护都可能造成干扰。七、OAuth 回调端点与各 Provider 差异7.1 回调端点清单以当前仓库源码为准所有服务的回调路径与 scope 均已在本仓库实现可逐一对照服务OAuth 发起路由回调路由请求的 scope源码可查Google Driveapp/api/google-drive/oauth/route.ts/api/google-drive/callback由路由参数构造OneDriveapp/api/onedrive/oauth/route.ts/api/onedrive/callback由路由参数构造GitHubapp/api/github/oauth/route.ts/api/github/callbackrepo,userDropboxapp/api/dropbox/oauth/route.ts/api/dropbox/callback由路由参数构造Bitbucketapp/api/bitbucket/oauth/route.ts/api/bitbucket/callbackaccount repository每条回调路由都基于getAppUrl()拼出 redirect URI并在 token 交换阶段调用对应 Provider 的 token 端点如 Google 的https://oauth2.googleapis.com/token、微软的https://login.microsoftonline.com/consumers/oauth2/v2.0/token、Dropbox 的https://api.dropboxapi.com/oauth2/token、Bitbucket 的https://bitbucket.org/site/oauth2/access_token。失败时统一重定向回/?errorxxx_callback_failed类错误页。7.2 Provider 侧配置策略差异todo.md 的 OAuth Next Steps 段基于对各 Provider 官方要求的核对得出一个关键结论——各家对回调地址的登记策略差异很大不能一刀切Google 与 MicrosoftOneDrive支持注册多个redirect URI可同时保留 localhost 与生产地址GitHub OAuth App只允许单一Authorization callback URL生产环境要么改地址要么新建 AppBitbucket OAuth consumer使用单个回调 baseDropbox要求精确匹配注册的 redirect URIMedium已不再允许创建新集成。完整的生产环境变量清单与部署后测试清单沉淀在 docs/PRODUCTION-OAUTH-CHECKLIST.md每项服务需在 Provider 控制台登记https://你的域名/api/{service}/callback并在 Vercel 中设置对应的CLIENT_ID/CLIENT_SECRET与关键的NEXT_PUBLIC_APP_URL部署后需逐一实测 Connect → List Files → Save File → Import File 全链路以及全部导出格式、拖拽导入、图片上传、Zen/滚动同步/夜间模式开关。该文档还强调NEXT_PUBLIC_APP_URL是所有 OAuth 回调构造 redirect URI 的基石且 OAuth App 支持多 redirect URI 时可在生产地址之外保留 localhost 以兼顾本地开发。八、PDF 导出故障排查与 serverless 修复8.1 故障复现与根因定位上线验证在 PDF 导出上栽了跟头beta 环境的POST /api/export/pdf在feature/nextjs-migration分支上返回500。排查过程todo.md 逐条记录在打开的 Chrome 实例中复现 beta 端浏览器行为确认用户可见错误通过 Vercel 日志确认真实失败发生在服务端POST /api/export/pdf→ 500本地直接调用旧的mdToPdf()复现根因Could not find Chrome (ver. 143.0.7499.192)定位实现缺陷旧实现基于md-to-pdf它启动 Puppeteer 时没有采用与 Vercel 兼容的 Chromium 策略且在 barecatch中吞掉了底层异常旧设计可见于 docs/plans/2026-01-19-nextjs-migration-design.md 中的 md-to-pdf 方案。8.2 修复方案puppeteer-core sparticuz/chromium修复后的实现落在 lib/pdf.ts 的renderPdfBuffer({ markdown, title })核心链路renderMarkdown(markdown)复用既有 Dillinger markdown 渲染管线renderHtmlDocument({ title, html, styled: true })生成带样式的完整 HTML 文档resolveChromeExecutablePath()区分运行时function isServerlessRuntime() { return Boolean(process.env.VERCEL || process.env.AWS_EXECUTION_ENV); }Serverless 环境调用sparticuz/chromium.executablePath()获取打包的 Chromium并以headless: shell启动配合chromium.args默认参数本地环境按候选列表探测系统 Chrome——PUPPETEER_EXECUTABLE_PATH环境变量优先其次 macOS 的Google Chrome/Chrome Canary、Linux 的google-chrome-stable/chromium-browser等全部缺失则抛出提示设置PUPPETEER_EXECUTABLE_PATH的明确错误。page.setContent(html, { waitUntil: networkidle0 })→emulateMediaType(screen)→page.pdf()输出选项为A4、四边 20mm 边距、printBackground: true默认视口 1280×720。路由层 app/api/export/pdf/route.ts 保持简洁语义缺少markdown返回 400成功返回Content-Type: application/pdf与Content-Disposition: attachment; filename...文件名经 lib/export.ts 的getExportFilename规范化为.pdf失败记录错误并返回 500。路由声明dynamic force-dynamic与runtime nodejs。8.3 配套的三处关键配置为了让 Chromium 在 Vercel 的 Node 函数中真正可用修复同时改了两处配置todo.md 明确记录next.config.mjsexperimental.serverComponentsExternalPackages: [sparticuz/chromium, puppeteer-core]让这两个包以外部包形式参与服务端打包vercel.json为app/api/export/pdf/route.ts增加函数 include 规则把sparticuz/chromium/bin下的 brotli 资源一并打入部署包functions: { app/api/export/pdf/route.ts: { includeFiles: node_modules/sparticuz/chromium/bin/**/* } }这一条不是可选的——首次托管部署正是因为部署包缺失sparticuz/chromium/bin而再次失败加上 include 规则后才解决。8.4 回归测试与最终托管验证新增的路由级回归测试 tests/routes/export-pdf.route.test.ts 覆盖三种行为缺markdown→ 400正常生成 → 200Content-Type: application/pdfContent-Disposition含filenameExported.pdf响应体包含 PDF 魔数%PDF-1.4renderPdfBuffer以 mock 注入生成失败mock reject→ 500且console.error被 spy 吞掉以避免噪音。本地验证链todo.md 记录依次通过npm run lint、npm run typecheck、npm run test:unit、npm run build、npm run verify并做了活体冒烟——本地POST http://127.0.0.1:3015/api/export/pdf返回一页有效 PDF。修复提交序列记录在origin/feature/nextjs-migrationb47a3ad90dc989f9ba180075f5e34b0ae480c7f3、60fdcd5535e12625fffdba92bec807ea21b6b4ea、c2dea1386ea7b299ab7a3f5f51ec8f2d6ea07f8c。最终托管验证通过受保护的POST /api/export/pdf在beta.dillinger.io返回HTTP/2 200、Content-Type: application/pdf、Content-Disposition: attachment; filenamebeta-smoke.pdf与合法的 PDF 响应体——serverless 环境下的 PDF 导出问题就此闭环。九、经验沉淀与残余风险从 tasks/lessons.md 与 todo.md 的 Review 段可以提炼出本次迁移收尾最有价值的方法论发布范围必须可执行、可证明把达到 README 与迁移文档声明的行为作为冻结目标用自动化测试与浏览器 E2E 作为本地证据而不是凭口头承诺验证基础设施先行T2 在 T3 之前先搭 Vitest Playwright 再补 parity任何行为修复都能立刻沉淀为回归用例上线策略要为 OAuth 服务选择稳定 beta 分支 固定域名beta.dillinger.io而非临时 Preview URL因为第三方回调需要固定的回调地址NEXT_PUBLIC_APP_URL是所有 redirect URI 的唯一事实来源lib/env.tsserverless 环境下的 Chromium 不是装个依赖就能用需要sparticuz/chromium的打包二进制 puppeteer-core显式指定可执行路径 next.config.mjs外部包声明 vercel.json函数 include 规则四者缺一不可部署保护会挡掉一切第三方跳转Vercel Authentication 让beta.dillinger.io返回 401导致公网 beta 与 OAuth 回调测试受阻——这类基础设施级阻塞应在上线计划中提前识别。todo.md 同时点明了部署后仍需完成的高风险检查Vercel 上的 PDF 导出已完成修复与验证、各 OAuth 回调的端到端实测、以及 beta 部署保护对第三方回调跳转的潜在干扰。这些构成了 Dillinger Next.js 迁移从本地验证通过走向生产可用的最后一道关卡。结语从冻结发布范围、搭建 Vitest Playwright 双轨验证到恢复 markdown/预览/导入导出 parity、统一 OAuth base URL再到 Vercel 上线与 PDF 导出的 serverless 修复Dillinger 的 Next.js 迁移收尾展示了一条可复制的交付路径每一项行为承诺都有自动化测试与浏览器证据背书每一次线上变更都先过验证闸门。对于正在把遗留前端迁移到 Next.js 的团队本文记录的任务依赖编排、verify门禁脚本、固定回调地址的 beta 上线策略以及serverless Chromium 四件套配置都是可以直接落地的工程实践。赞分享前端开发工具【免费下载链接】dillingerThe last Markdown editor, ever.项目地址https://gitcode.com/gh_mirrors/di/dillinger点击查看免费下载相关推荐oh-my-codex 0.20.4 发布就绪记录全解读冻结范围、质量门禁与发布序列oh my codex 0.20.4 发布就绪记录全解读冻结范围、质量门禁与发布序列 导读 本文围绕 oh my codex 的 0.20.4 补丁版本发布人工智能AI AgentAgent 编排Agent 工作流CLI开发工具AI 技能Slate v2 发布候选冻结实战plate 项目基于关卡门禁的版本迁移收口方法论Slate v2 发布候选冻结实战plate 项目基于关卡门禁的版本迁移收口方法论 导读 本文以 plate 仓库中 2026 04 08 slate v2前端富文本UI组件DLSS Swapper 完整指南DLSS 版本切换与 DLL 管理教程DLSS Swapper 完整指南DLSS 版本切换与 DLL 管理教程 DLSS Swapper 是一款运行在 Windows 上的图形工具用来下载、管理桌面应用上一篇探索ASP.NET Dependency Injection轻量级、强大的服务容器下一篇Cutelyst构建高效Web应用的秘密武器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考