数据库后端【免费下载链接】convex-backendThe open-source reactive database for app developers项目地址https://gitcode.com/gh_mirrors/co/convex-backend点击查看免费下载本指南围绕仓库中的 bundle-size 演示项目展开该项目是一个专门用于检测 Convex 客户端库在各主流打包器Vite/Rollup、esbuild、webpack下打包体积的基准工程。读完本文你将掌握该基准项目的完整结构、构建与统计脚本的工作原理、React 依赖体积的估算方式以及如何在自己的 Convex 应用中复现这一套包体积测量流程。项目定位为什么需要一个 bundle-size 基准工程Convex 是一个面向应用开发者的开源响应式数据库其前端通过convexnpm 包暴露客户端 API。对前端项目而言引入的 SDK 体积直接影响首屏加载性能因此仓库内维护了这样一个最小化的演示项目其 README.md 明确说明了它的用途A simple project that imports everything we expect users to import, for checking bundle size in bundlers.也就是说这个项目刻意导入了所有预期用户会使用的 API形成一条最大导入面的基准输入然后用多个打包器分别构建并对比产物体积。这样既能监控 convex 客户端库体积随版本演进的趋势也能为使用者提供引入 Convex 大概会增加多少字节的量化参考。从仓库结构看bundle-size 目录下同时提供了 Vite、esbuild、webpack 三套构建配置以及一个汇总统计脚本 analyze.mjs是一套代码、多打包器交叉验证的典型基准工程布局。项目结构与导入面设计目录总览npm-packages/private-demos/bundle-size/ ├── analyze.mjs # 汇总各打包器产物字节数并输出 ├── index.html # Vite 入口 HTML ├── package.json # 依赖与构建脚本 ├── tsconfig.json ├── vite.config.mts # Vite 配置 依赖图导出插件 ├── webpack.config.cjs # webpack 配置 ├── convex/ # Convex 后端函数 │ ├── listMessages.ts # query读取消息 │ ├── sendMessage.ts # mutation写入消息 │ └── _generated/ # 类型安全的 API 生成文件 └── src/ ├── App.tsx # 使用 useQuery / useMutation ├── common.ts # 共享类型导入 Id ├── main.tsx # ConvexProvider 入口 └── vite-env.d.ts客户端 API 导入面入口文件 src/main.tsx 导入了 React 客户端最核心的两个构件ConvexProviderContext Provider与ConvexReactClient客户端实例并用import.meta.env.VITE_CONVEX_URL读取部署地址import { StrictMode } from react; import ReactDOM from react-dom/client; import App from ./App; import { ConvexProvider, ConvexReactClient } from convex/react; const convex new ConvexReactClient(import.meta.env.VITE_CONVEX_URL); ReactDOM.createRoot(document.getElementById(root)!).render( StrictMode ConvexProvider client{convex} App / /ConvexProvider /StrictMode, );src/App.tsx 进一步使用了 Hooks API——useQuery订阅查询结果、useMutation触发变更覆盖了响应式订阅的核心数据路径import { useMutation, useQuery } from convex/react; import { api } from ../convex/_generated/api; const messages useQuery(api.listMessages.default) || []; const sendMessage useMutation(api.sendMessage.default);src/common.ts 还导入了convex/_generated/dataModel中的Id类型用于定义消息的数据结构从而把类型层面的导入也纳入打包范围import { Id } from ../convex/_generated/dataModel; export type Message { _id: Id; _creationTime: number; body: string; author: string; };后端函数面convex/listMessages.ts 是一个典型的query遍历messages表并返回全部消息import { query } from ./_generated/server; export default query({ handler: async ({ db }): PromiseMessage[] { return await db.query(messages).collect(); }, });convex/sendMessage.ts 是一个典型的mutation将消息写入同一张表import { mutation } from ./_generated/server; export default mutation( ({ db }, { body, author }: { body: string; author: string }) { const message { body, author }; return db.insert(messages, message); }, );从源码结构看这份基准输入刻意选择了最典型的 Convex 用法一个 query、一个 mutation、一个响应式组件订阅加上_generated代码生成层的类型导入。这正是绝大多数 Convex 应用首次接入时的真实导入形态用它测出的体积对普通用户最有参考价值。构建脚本一键跑完三套打包器package.json 中的 scripts 字段定义了完整的测量流水线{ scripts: { dev-vite: vite, analyze: npm run build npm run analyze-webpack npm run analyze-esbuild ./analyze.mjs, analyze-webpack: webpack-cli webpack-cli --profile --json dist/webpack-stats.json, analyze-esbuild: esbuild src/main.tsx --bundle --minify --metafiledist/esbuild.json --outfiledist/esbuild-output --define:process.env.NODE_ENV\production\, build: rm -rf dist tsc vite build mv parcel-bundle-buddy.json dist, clean: rm -rf dist } }各脚本职责如下脚本作用build清空dist→tsc类型检查 →vite build产出 Vite 构建物 → 把parcel-bundle-buddy.json依赖图移入distanalyze-webpack先执行一次webpack-cli生成产物再以--profile --json模式输出模块统计到dist/webpack-stats.jsonanalyze-esbuild用 esbuild 以生产模式--minify打包src/main.tsx同时通过--metafiledist/esbuild.json导出元数据产物写入dist/esbuild-outputanalyze按build→ webpack → esbuild →./analyze.mjs的顺序串起整个测量流程并打印结果dev-vite启动 Vite 开发服务器便于人工查看演示应用值得注意的是 esbuild 命令行中通过--define:process.env.NODE_ENVproduction注入环境变量确保 React 等依赖以生产版本参与打包webpack 则在mode: production下构建。三套工具都以生产/压缩形态输出保证体积对比口径一致。依赖方面convex以workspace:*的形式引用npm-packages 的 pnpm workspace 内联版本React 固定为^18.0.0构建工具链由vite、esbuild、webpack、webpack-cli、ts-loader、vitejs/plugin-react与typescript组成。三套打包器配置解析VitebuildEnd 钩子导出模块依赖图vite.config.mts 在标准 React 插件之外注册了一个自定义插件在buildEnd阶段遍历所有模块把非外部模块之间的导入关系写入parcel-bundle-buddy.jsonimport fs from fs; import path from path; import react from vitejs/plugin-react; export default { plugins: [ react(), { buildEnd() { const deps []; for (const id of this.getModuleIds()) { const m this.getModuleInfo(id); if (m ! null !m.isExternal) { for (const target of m.importedIds) { deps.push({ source: m.id, target }); } } } fs.writeFileSync( path.join(__dirname, parcel-bundle-buddy.json), JSON.stringify(deps, null, 2), ); }, }, ], build: { sourcemap: true, }, };这份{ source, target }形式的依赖边列表可以交给 Bundle Buddy 之类的依赖可视化工具从模块依赖图层面分析体积来源。同时开启了sourcemap: true便于在体积分析时追溯每个模块的原始源码位置。Vite 的产物会输出到dist/assets/供后续统计脚本定位。webpack经典 ts-loader 生产配置webpack.config.cjs 是标准的 TypeScript 打包配置入口为./src/main.tsx产物命名为webpack.bundle.js并输出到dist通过ts-loader处理.tsx/.ts文件开启source-mapdevtoolmodule.exports { mode: production, devtool: source-map, entry: ./src/main.tsx, output: { path: path.resolve(__dirname, dist), filename: webpack.bundle.js, }, resolve: { extensions: [.tsx, .ts, .js], }, module: { rules: [ { test: /\.tsx?$/, use: ts-loader, exclude: /node_modules/, }, ], }, };esbuild纯命令行零配置esbuild 没有独立配置文件全部参数内联在analyze-esbuild脚本中--bundle递归打包、--minify压缩、--metafile输出构建元数据、--define注入生产环境变量。它代表极速打包器一档产物字节数是三套工具中结构最精简的参考。统计脚本统一口径下的体积对比analyze.mjs 是测量的收口环节负责读取三套打包器的产物并输出统一格式的对比结果。脚本开头定义了一个 React 体积估算常量const REACT_EST (0 6000 // react (split the difference between v17 and v18) 125000 // react-dom );即 React 本体约 6 KB、react-dom 约 125 KB合计约 131 KB。由于该项目的依赖中同时存在 React 与 Convex统计脚本用产物总字节数减去 React 估算值的方式估算Convex 客户端库自身的净体积这也是演示应用中可被优化的主要部分。随后脚本分别读取三类产物esbuild解析dist/esbuild.json的outputs[dist/esbuild-output]字段得到字节数Parcel/Vite扫描dist/assets/下所有.js文件Vite 的 Rollup 产物默认带内容哈希命名因此用过滤方式定位取文件大小webpack直接读取dist/webpack.bundle.js的文件大小。format()函数负责把字节数转换为更易读的 kilobytes 展示最终依次打印三行结果并额外输出三者的平均值。完整输出形如esbuild: 221234 bytes without react est. 91 kilobytes parcel: 225678 bytes without react est. 95 kilobytes webpack: 230123 bytes without react est. 100 kilobytes上表数值为示意实际以本机运行npm run analyze的结果为准。复现与运行指南在npm-packagesworkspace 下安装依赖后进入private-demos/bundle-size目录执行npm run analyze流程会自动完成build含 tsc 类型检查与 Vite 构建、webpack 与 esbuild 的生产构建最后运行 analyze.mjs 打印三套打包器的体积对比与 Convex 净体积估算。若只想查看演示应用本身可运行npm run dev-vite并在本地 Vite 开发服务器中体验 src/App.tsx 的聊天界面后端函数见 convex/listMessages.ts 与 convex/sendMessage.ts。需要清理产物时执行npm run clean关于 Bundle BuddyREADME 中建议使用 Bundle Buddy 查看各打包器的输出。npm run build生成的parcel-bundle-buddy.json模块依赖边列表与 webpack 的dist/webpack-stats.json带--profile --json的模块统计都是为这类依赖可视化工具准备的输入可在本地或对应工具界面中分析具体是哪些模块占据了体积。注意事项与测量口径体积口径所有产物均为生产模式minify输出esbuild 与 webpack 通过--define/mode确保 React 使用 production 构建避免开发版体积干扰结论。React 估算扣除REACT_EST是一个固定估算值react 6 KB react-dom 125 KB脚本注释说明这是在 React 17 与 18 之间取的折中因此without react est.一行的数值是近似值不代表精确的 convex 净体积。版本敏感性由于convex以workspace:*引用测得的体积会随 npm-packages 内 convex 包的当前源码版本变化若要横向对比历史版本应在对应 commit 上分别执行测量。多打包器差异三套工具因 tree-shaking 能力、代码分割策略不同产物字节数会有差异平均值可用于观察整体趋势而非精确对标。小结bundle-size 基准项目以最小完整导入面为输入通过 Vite、esbuild、webpack 三套生产构建与 analyze.mjs 的统一统计给出了 Convex 客户端库包体积的可量化观测手段。它的工程手法——buildEnd钩子导出依赖图、--metafile元数据收集、React 体积扣除估算——同样可以直接迁移到任何希望监控自身 SDK 体积的 React 项目中是一套低成本、可复现的前端体积基准测试范式。赞分享数据库后端【免费下载链接】convex-backendThe open-source reactive database for app developers项目地址https://gitcode.com/gh_mirrors/co/convex-backend点击查看免费下载相关推荐AdGuard ContentBlocker常见问题解决广告拦截失效这篇文章帮你搞定AdGuard ContentBlocker常见问题解决广告拦截失效这篇文章帮你搞定 AdGuard ContentBlocker是一款专为Yandex浏览数据库后端深度包检测绕过指南用GoodbyeDPI解锁被封锁的网络世界 深度包检测绕过指南用GoodbyeDPI解锁被封锁的网络世界 你是否曾经遇到过这样的情况明明网络连接正常某些网站却始终无法访问浏览器显示连接被重网络通信5分钟掌握Czkawka免费高效的终极磁盘清理解决方案5分钟掌握Czkawka免费高效的终极磁盘清理解决方案 你是否曾因为磁盘空间不足的警告而烦恼现代电脑中隐藏的重复文件、相似图片和系统冗余正悄悄吞噬你的存桌面应用上一篇Qwen3-VL-30B-A3B-Instruct实战教程10个图像描述生成与多轮对话示例下一篇Nemotron-3-Nano-Omni-30B-A3B-Reasoning-FP8硬件需求指南从RTX 5090到DGX Spark的完整配置创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Convex 前端包体积基准测试：用 Vite、esbuild 与 webpack 实测 convex 客户端库的 Bundle Size
数据库后端【免费下载链接】convex-backendThe open-source reactive database for app developers项目地址https://gitcode.com/gh_mirrors/co/convex-backend点击查看免费下载本指南围绕仓库中的 bundle-size 演示项目展开该项目是一个专门用于检测 Convex 客户端库在各主流打包器Vite/Rollup、esbuild、webpack下打包体积的基准工程。读完本文你将掌握该基准项目的完整结构、构建与统计脚本的工作原理、React 依赖体积的估算方式以及如何在自己的 Convex 应用中复现这一套包体积测量流程。项目定位为什么需要一个 bundle-size 基准工程Convex 是一个面向应用开发者的开源响应式数据库其前端通过convexnpm 包暴露客户端 API。对前端项目而言引入的 SDK 体积直接影响首屏加载性能因此仓库内维护了这样一个最小化的演示项目其 README.md 明确说明了它的用途A simple project that imports everything we expect users to import, for checking bundle size in bundlers.也就是说这个项目刻意导入了所有预期用户会使用的 API形成一条最大导入面的基准输入然后用多个打包器分别构建并对比产物体积。这样既能监控 convex 客户端库体积随版本演进的趋势也能为使用者提供引入 Convex 大概会增加多少字节的量化参考。从仓库结构看bundle-size 目录下同时提供了 Vite、esbuild、webpack 三套构建配置以及一个汇总统计脚本 analyze.mjs是一套代码、多打包器交叉验证的典型基准工程布局。项目结构与导入面设计目录总览npm-packages/private-demos/bundle-size/ ├── analyze.mjs # 汇总各打包器产物字节数并输出 ├── index.html # Vite 入口 HTML ├── package.json # 依赖与构建脚本 ├── tsconfig.json ├── vite.config.mts # Vite 配置 依赖图导出插件 ├── webpack.config.cjs # webpack 配置 ├── convex/ # Convex 后端函数 │ ├── listMessages.ts # query读取消息 │ ├── sendMessage.ts # mutation写入消息 │ └── _generated/ # 类型安全的 API 生成文件 └── src/ ├── App.tsx # 使用 useQuery / useMutation ├── common.ts # 共享类型导入 Id ├── main.tsx # ConvexProvider 入口 └── vite-env.d.ts客户端 API 导入面入口文件 src/main.tsx 导入了 React 客户端最核心的两个构件ConvexProviderContext Provider与ConvexReactClient客户端实例并用import.meta.env.VITE_CONVEX_URL读取部署地址import { StrictMode } from react; import ReactDOM from react-dom/client; import App from ./App; import { ConvexProvider, ConvexReactClient } from convex/react; const convex new ConvexReactClient(import.meta.env.VITE_CONVEX_URL); ReactDOM.createRoot(document.getElementById(root)!).render( StrictMode ConvexProvider client{convex} App / /ConvexProvider /StrictMode, );src/App.tsx 进一步使用了 Hooks API——useQuery订阅查询结果、useMutation触发变更覆盖了响应式订阅的核心数据路径import { useMutation, useQuery } from convex/react; import { api } from ../convex/_generated/api; const messages useQuery(api.listMessages.default) || []; const sendMessage useMutation(api.sendMessage.default);src/common.ts 还导入了convex/_generated/dataModel中的Id类型用于定义消息的数据结构从而把类型层面的导入也纳入打包范围import { Id } from ../convex/_generated/dataModel; export type Message { _id: Id; _creationTime: number; body: string; author: string; };后端函数面convex/listMessages.ts 是一个典型的query遍历messages表并返回全部消息import { query } from ./_generated/server; export default query({ handler: async ({ db }): PromiseMessage[] { return await db.query(messages).collect(); }, });convex/sendMessage.ts 是一个典型的mutation将消息写入同一张表import { mutation } from ./_generated/server; export default mutation( ({ db }, { body, author }: { body: string; author: string }) { const message { body, author }; return db.insert(messages, message); }, );从源码结构看这份基准输入刻意选择了最典型的 Convex 用法一个 query、一个 mutation、一个响应式组件订阅加上_generated代码生成层的类型导入。这正是绝大多数 Convex 应用首次接入时的真实导入形态用它测出的体积对普通用户最有参考价值。构建脚本一键跑完三套打包器package.json 中的 scripts 字段定义了完整的测量流水线{ scripts: { dev-vite: vite, analyze: npm run build npm run analyze-webpack npm run analyze-esbuild ./analyze.mjs, analyze-webpack: webpack-cli webpack-cli --profile --json dist/webpack-stats.json, analyze-esbuild: esbuild src/main.tsx --bundle --minify --metafiledist/esbuild.json --outfiledist/esbuild-output --define:process.env.NODE_ENV\production\, build: rm -rf dist tsc vite build mv parcel-bundle-buddy.json dist, clean: rm -rf dist } }各脚本职责如下脚本作用build清空dist→tsc类型检查 →vite build产出 Vite 构建物 → 把parcel-bundle-buddy.json依赖图移入distanalyze-webpack先执行一次webpack-cli生成产物再以--profile --json模式输出模块统计到dist/webpack-stats.jsonanalyze-esbuild用 esbuild 以生产模式--minify打包src/main.tsx同时通过--metafiledist/esbuild.json导出元数据产物写入dist/esbuild-outputanalyze按build→ webpack → esbuild →./analyze.mjs的顺序串起整个测量流程并打印结果dev-vite启动 Vite 开发服务器便于人工查看演示应用值得注意的是 esbuild 命令行中通过--define:process.env.NODE_ENVproduction注入环境变量确保 React 等依赖以生产版本参与打包webpack 则在mode: production下构建。三套工具都以生产/压缩形态输出保证体积对比口径一致。依赖方面convex以workspace:*的形式引用npm-packages 的 pnpm workspace 内联版本React 固定为^18.0.0构建工具链由vite、esbuild、webpack、webpack-cli、ts-loader、vitejs/plugin-react与typescript组成。三套打包器配置解析VitebuildEnd 钩子导出模块依赖图vite.config.mts 在标准 React 插件之外注册了一个自定义插件在buildEnd阶段遍历所有模块把非外部模块之间的导入关系写入parcel-bundle-buddy.jsonimport fs from fs; import path from path; import react from vitejs/plugin-react; export default { plugins: [ react(), { buildEnd() { const deps []; for (const id of this.getModuleIds()) { const m this.getModuleInfo(id); if (m ! null !m.isExternal) { for (const target of m.importedIds) { deps.push({ source: m.id, target }); } } } fs.writeFileSync( path.join(__dirname, parcel-bundle-buddy.json), JSON.stringify(deps, null, 2), ); }, }, ], build: { sourcemap: true, }, };这份{ source, target }形式的依赖边列表可以交给 Bundle Buddy 之类的依赖可视化工具从模块依赖图层面分析体积来源。同时开启了sourcemap: true便于在体积分析时追溯每个模块的原始源码位置。Vite 的产物会输出到dist/assets/供后续统计脚本定位。webpack经典 ts-loader 生产配置webpack.config.cjs 是标准的 TypeScript 打包配置入口为./src/main.tsx产物命名为webpack.bundle.js并输出到dist通过ts-loader处理.tsx/.ts文件开启source-mapdevtoolmodule.exports { mode: production, devtool: source-map, entry: ./src/main.tsx, output: { path: path.resolve(__dirname, dist), filename: webpack.bundle.js, }, resolve: { extensions: [.tsx, .ts, .js], }, module: { rules: [ { test: /\.tsx?$/, use: ts-loader, exclude: /node_modules/, }, ], }, };esbuild纯命令行零配置esbuild 没有独立配置文件全部参数内联在analyze-esbuild脚本中--bundle递归打包、--minify压缩、--metafile输出构建元数据、--define注入生产环境变量。它代表极速打包器一档产物字节数是三套工具中结构最精简的参考。统计脚本统一口径下的体积对比analyze.mjs 是测量的收口环节负责读取三套打包器的产物并输出统一格式的对比结果。脚本开头定义了一个 React 体积估算常量const REACT_EST (0 6000 // react (split the difference between v17 and v18) 125000 // react-dom );即 React 本体约 6 KB、react-dom 约 125 KB合计约 131 KB。由于该项目的依赖中同时存在 React 与 Convex统计脚本用产物总字节数减去 React 估算值的方式估算Convex 客户端库自身的净体积这也是演示应用中可被优化的主要部分。随后脚本分别读取三类产物esbuild解析dist/esbuild.json的outputs[dist/esbuild-output]字段得到字节数Parcel/Vite扫描dist/assets/下所有.js文件Vite 的 Rollup 产物默认带内容哈希命名因此用过滤方式定位取文件大小webpack直接读取dist/webpack.bundle.js的文件大小。format()函数负责把字节数转换为更易读的 kilobytes 展示最终依次打印三行结果并额外输出三者的平均值。完整输出形如esbuild: 221234 bytes without react est. 91 kilobytes parcel: 225678 bytes without react est. 95 kilobytes webpack: 230123 bytes without react est. 100 kilobytes上表数值为示意实际以本机运行npm run analyze的结果为准。复现与运行指南在npm-packagesworkspace 下安装依赖后进入private-demos/bundle-size目录执行npm run analyze流程会自动完成build含 tsc 类型检查与 Vite 构建、webpack 与 esbuild 的生产构建最后运行 analyze.mjs 打印三套打包器的体积对比与 Convex 净体积估算。若只想查看演示应用本身可运行npm run dev-vite并在本地 Vite 开发服务器中体验 src/App.tsx 的聊天界面后端函数见 convex/listMessages.ts 与 convex/sendMessage.ts。需要清理产物时执行npm run clean关于 Bundle BuddyREADME 中建议使用 Bundle Buddy 查看各打包器的输出。npm run build生成的parcel-bundle-buddy.json模块依赖边列表与 webpack 的dist/webpack-stats.json带--profile --json的模块统计都是为这类依赖可视化工具准备的输入可在本地或对应工具界面中分析具体是哪些模块占据了体积。注意事项与测量口径体积口径所有产物均为生产模式minify输出esbuild 与 webpack 通过--define/mode确保 React 使用 production 构建避免开发版体积干扰结论。React 估算扣除REACT_EST是一个固定估算值react 6 KB react-dom 125 KB脚本注释说明这是在 React 17 与 18 之间取的折中因此without react est.一行的数值是近似值不代表精确的 convex 净体积。版本敏感性由于convex以workspace:*引用测得的体积会随 npm-packages 内 convex 包的当前源码版本变化若要横向对比历史版本应在对应 commit 上分别执行测量。多打包器差异三套工具因 tree-shaking 能力、代码分割策略不同产物字节数会有差异平均值可用于观察整体趋势而非精确对标。小结bundle-size 基准项目以最小完整导入面为输入通过 Vite、esbuild、webpack 三套生产构建与 analyze.mjs 的统一统计给出了 Convex 客户端库包体积的可量化观测手段。它的工程手法——buildEnd钩子导出依赖图、--metafile元数据收集、React 体积扣除估算——同样可以直接迁移到任何希望监控自身 SDK 体积的 React 项目中是一套低成本、可复现的前端体积基准测试范式。赞分享数据库后端【免费下载链接】convex-backendThe open-source reactive database for app developers项目地址https://gitcode.com/gh_mirrors/co/convex-backend点击查看免费下载相关推荐AdGuard ContentBlocker常见问题解决广告拦截失效这篇文章帮你搞定AdGuard ContentBlocker常见问题解决广告拦截失效这篇文章帮你搞定 AdGuard ContentBlocker是一款专为Yandex浏览数据库后端深度包检测绕过指南用GoodbyeDPI解锁被封锁的网络世界 深度包检测绕过指南用GoodbyeDPI解锁被封锁的网络世界 你是否曾经遇到过这样的情况明明网络连接正常某些网站却始终无法访问浏览器显示连接被重网络通信5分钟掌握Czkawka免费高效的终极磁盘清理解决方案5分钟掌握Czkawka免费高效的终极磁盘清理解决方案 你是否曾因为磁盘空间不足的警告而烦恼现代电脑中隐藏的重复文件、相似图片和系统冗余正悄悄吞噬你的存桌面应用上一篇Qwen3-VL-30B-A3B-Instruct实战教程10个图像描述生成与多轮对话示例下一篇Nemotron-3-Nano-Omni-30B-A3B-Reasoning-FP8硬件需求指南从RTX 5090到DGX Spark的完整配置创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考