北京
一篇讲lint规则的文章，通常有个共同的缺口。
作者写"这条规则能捕获算法：["HS256", "none"]"，贴一段代码，再贴一个检测结果。你读完了，心里想的是：行，但它对我的代码有效吗？文章回答不了这个问题。它只能展示别人的代码，展示作者在自己机器上跑出来的结果，截图放进文章里。你想知道这工具值不值得装，得先把它装一遍。
所以这位开发者不再写规则了，他直接把linter（代码检查工具）搬到了文章里。在那篇讲JWT（JSON Web Token，一种身份验证令牌标准）的文章里，现在有一个按钮，写着"Try it live"。点一下，粘贴你自己的jwt.verify调用，那条正式发布的规则就会在你的浏览器里、随着你的每一次按键实时运行，所有操作都不离开页面。
这件事之所以能实现，靠的是一个出乎意料的数字。
ESLint的浏览器版本
ESLint官方提供了一个浏览器构建版本。eslint/universal导出的Linter类，其公开接口不依赖任何Node.js环境——你把源代码和一份flat config（扁平配置）交给它，它把检测结果返回给你。没有文件系统，没有命令行工具，没有插件解析。
把两个真实的安全插件一起打包进去，体积是多少？
362KB，这是网络传输的大小，而且生产环境用的是brotli压缩——作者检查了响应头确认这一点。这个体积相当于一张中等尺寸的主图，比大多数营销网站为了渲染一个Cookie横幅加载的JavaScript还要小。
这个数字就是全部论点。如果是3MB，你只能写一篇关于规则的文章；但362KB，你可以直接把规则本身交付出去。
而且它是懒加载的：打包文件藏在一个明确的开关后面，读者不主动点击，文章就不会加载任何额外资源。按钮在消耗流量之前，会先告诉你它要消耗多少。
三个组成部分
整套方案由三块拼成：一个worker（后台工作线程）、一个构建步骤、一个客户端接口。就这么多。
worker持有linter和插件，它从不与服务器通信。代码里，插件列表是枚举出来的，不是动态加载的——worker只打包嵌入文章明确指定的插件，请求其他任何插件都会报错。linter实例在worker内部创建，收到消息后执行verify方法，把检测结果通过postMessage传回主线程。
构建步骤才是真正有意思的部分。用esbuild的buildSync方法，配合几个路径别名和一段banner注释，把worker入口文件打包成一个IIFE格式的、压缩过的、面向浏览器的单文件。Node.js特有的模块，通过shim文件在浏览器环境里模拟掉。
这个方案的巧妙之处在于，它把"写文章"和"跑代码"这两件事彻底解耦了。文章是静态的，但代码检查是活的。读者不再需要信任作者的截图，他们可以直接验证。
成本与收益的重新计算
从技术角度看，这不算什么革命性的创新——Web Worker、esbuild、ESLint的universal构建，这些技术都是现成的。真正的创新在于成本结构的改变。
过去，一篇技术文章的传播路径是：读者读文章 → 觉得有用 → 安装工具 → 跑一下 → 发现不适用 → 卸载。这个链条太长，每一步都在流失用户。
现在，路径变成了：读者读文章 → 点按钮 → 粘贴代码 → 立即看到结果。安装这个动作被完全省略了，而"立即看到结果"带来的反馈，比任何文字描述都有说服力。
362KB这个数字，恰好卡在了一个心理阈值上。它足够小，小到可以塞进一篇博客文章里而不觉得笨重；它又足够大，大到能承载两个真实的安全插件，跑出有实际意义的检测结果。
这不是一个关于ESLint的故事，这是一个关于交付方式的故事。当工具的体积缩小到一定程度，它就不再是工具，而变成了内容本身的一部分。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
