Now vibe coding, so learning hammer FE ?
《Portless:告别端口号的本地开发代理工具》
标签:#开发工具 #本地开发 #DevServer #HTTPS #Monorepo #Turborepo #Vercel
总结:
Portless 是 Vercel Labs 推出的本地开发代理工具,用
文章要点:
- 一键替换端口号:把
- 开箱即用的 HTTPS/HTTP/2:首次运行自动生成本地 CA 并加入系统信任,浏览器零警告;HTTP/2 多路复用解决 Vite 等开发服务器大量并发请求的性能瓶颈
- 框架零配置适配:自动识别 Next.js、Express、Nuxt、Vite、Astro、Expo 等框架,通过
- Monorepo 与 Turborepo 原生支持:通过
- Git Worktree 智能隔离:自动检测 Git Worktree,用分支名作为子域名前缀,避免多个工作区端口冲突,无需额外配置
- 多场景网络共享:LAN 模式通过 mDNS 让手机等设备访问
- 灵活的子域名与自定义域名:支持
文章URL:https://github.com/vercel-labs/portless
标签:#开发工具 #本地开发 #DevServer #HTTPS #Monorepo #Turborepo #Vercel
总结:
Portless 是 Vercel Labs 推出的本地开发代理工具,用
https://myapp.localhost 这类稳定命名 URL 彻底取代难记的端口号。它默认开启 HTTPS + HTTP/2,自动分配端口并适配 Next.js、Vite、Astro 等主流框架,支持 Monorepo 多包路由、Git Worktree 自动子域名、LAN 内网共享及 Tailscale 团队协作,让本地开发环境对人类和 AI 代理都更加友好。文章要点:
- 一键替换端口号:把
localhost:3000 变成 https://myapp.localhost,告别记端口的烦恼,对人类可读、对 AI 代理也更友好- 开箱即用的 HTTPS/HTTP/2:首次运行自动生成本地 CA 并加入系统信任,浏览器零警告;HTTP/2 多路复用解决 Vite 等开发服务器大量并发请求的性能瓶颈
- 框架零配置适配:自动识别 Next.js、Express、Nuxt、Vite、Astro、Expo 等框架,通过
PORT 环境变量或自动注入 --port/--host 参数,无需手动改配置- Monorepo 与 Turborepo 原生支持:通过
portless.json 或 package.json 的 portless 字段统一管理多包路由,如 api.myapp.localhost 和 web.myapp.localhost,与 Turborepo 无缝集成- Git Worktree 智能隔离:自动检测 Git Worktree,用分支名作为子域名前缀,避免多个工作区端口冲突,无需额外配置
- 多场景网络共享:LAN 模式通过 mDNS 让手机等设备访问
.local 域名;Tailscale 集成支持团队内网共享,甚至通过 Funnel 一键暴露到公网- 灵活的子域名与自定义域名:支持
api.myapp.localhost 等子域名组织服务,也可切换 .test 等自定义 TLD,自动同步 /etc/hosts 保证 Safari 兼容文章URL:https://github.com/vercel-labs/portless
《垂直代码库:告别按类型分层,拥抱按业务域组织》
标签:#前端 #代码组织 #架构设计 #Monorepo #React #软件工程
总结:
本文主张前端代码库应从"水平分层"(按 components/hooks/utils 技术类型划分)转向"垂直切片"(按业务域/功能域组织)。作者以 Sentry 代码库十年演进为例,指出水平分层会导致代码分散、认知负荷高、耦合混乱;而垂直组织将同一业务域的组件、工具、类型内聚到一起,配合 Monorepo 的显式边界(exports/eslint-plugin-boundaries),能显著提升可维护性。虽然确定正确的垂直划分需要更多团队沟通,但这是支撑代码库长期演进的必要投资。
文章要点:
- 水平分层的隐患:把代码按 components / hooks / utils / types 分类虽然上手简单,但随着项目膨胀,同一业务逻辑会被拆得七零八落——比如 PageFilters 的组件、类型、工具函数散落在三个目录,改一个小需求要跳来跳去, cognitive load 直接拉满
- 垂直切片的核心思想:不按"技术类型"而按"业务域"分组,把同一个功能域(如 dashboard、profiling、billing)相关的组件、Hook、工具、类型全部收进一个目录;就像当年我们把 HTML/CSS/JS 从三层文件合并成组件一样,这次是更高维度的"关注点内聚"
- 与团队结构天然对齐:现代产品团队通常是端到端的功能团队(dashboard 团队、replay 团队),垂直代码结构让 CODEOWNERS 和包边界直接对应团队职责,谁负责什么一目了然
- 解决跨域复用焦虑:不是所有代码都严格属于某个页面,像 PageFilters 这种被多页面使用的通用能力,完全可以作为独立垂直域存在;关键是按"逻辑关联"而非"物理位置"来划分
- 用边界守护架构:垂直化后还需降低耦合,推荐通过 Monorepo + package.json#exports 显式暴露公共 API,或借助 eslint-plugin-boundaries 禁止深路径导入,把"私有实现"真正保护起来
- 没有银弹,但值得投入:确定合理的垂直域确实比"丢进 utils"更难,也可能出现不同团队重复造轮子;但作者认为这恰恰促进了团队沟通,而沟通本就是软件工程最难也最重要的部分
文章URL:
https://tkdodo.eu/blog/the-vertical-codebase
标签:#前端 #代码组织 #架构设计 #Monorepo #React #软件工程
总结:
本文主张前端代码库应从"水平分层"(按 components/hooks/utils 技术类型划分)转向"垂直切片"(按业务域/功能域组织)。作者以 Sentry 代码库十年演进为例,指出水平分层会导致代码分散、认知负荷高、耦合混乱;而垂直组织将同一业务域的组件、工具、类型内聚到一起,配合 Monorepo 的显式边界(exports/eslint-plugin-boundaries),能显著提升可维护性。虽然确定正确的垂直划分需要更多团队沟通,但这是支撑代码库长期演进的必要投资。
文章要点:
- 水平分层的隐患:把代码按 components / hooks / utils / types 分类虽然上手简单,但随着项目膨胀,同一业务逻辑会被拆得七零八落——比如 PageFilters 的组件、类型、工具函数散落在三个目录,改一个小需求要跳来跳去, cognitive load 直接拉满
- 垂直切片的核心思想:不按"技术类型"而按"业务域"分组,把同一个功能域(如 dashboard、profiling、billing)相关的组件、Hook、工具、类型全部收进一个目录;就像当年我们把 HTML/CSS/JS 从三层文件合并成组件一样,这次是更高维度的"关注点内聚"
- 与团队结构天然对齐:现代产品团队通常是端到端的功能团队(dashboard 团队、replay 团队),垂直代码结构让 CODEOWNERS 和包边界直接对应团队职责,谁负责什么一目了然
- 解决跨域复用焦虑:不是所有代码都严格属于某个页面,像 PageFilters 这种被多页面使用的通用能力,完全可以作为独立垂直域存在;关键是按"逻辑关联"而非"物理位置"来划分
- 用边界守护架构:垂直化后还需降低耦合,推荐通过 Monorepo + package.json#exports 显式暴露公共 API,或借助 eslint-plugin-boundaries 禁止深路径导入,把"私有实现"真正保护起来
- 没有银弹,但值得投入:确定合理的垂直域确实比"丢进 utils"更难,也可能出现不同团队重复造轮子;但作者认为这恰恰促进了团队沟通,而沟通本就是软件工程最难也最重要的部分
文章URL:
https://tkdodo.eu/blog/the-vertical-codebase