Valdi 路线图深度解读Web 渲染器与 bzlmod 迁移进行时以及明确不做的技术边界【免费下载链接】ValdiValdi is a cross-platform UI framework that delivers native performance without sacrificing developer velocity.项目地址: https://gitcode.com/gh_mirrors/val/Valdi导读本文以仓库根目录的 ROADMAP.md 为主线系统梳理 Valdi 当前正在推进的两大方向HTML/CSS Web 渲染器、bzlmod 模块化改造与四个明确不做的事项Swift/SwiftUI 运行时、WebSocket API、macOS Intel 支持、Windows 开发环境。读完本文你将能基于 Valdi 的真实演进方向判断它是否适合你的项目并掌握在 Web 目标尚未成熟、原生能力受限时利用 Polyglot 模块补齐短板的落地路径。Valdi 是一个跨平台 UI 框架目前已能将同一套 TypeScript 声明式代码渲染到 iOS、Android 与 macOS。官方路线图文档 ROADMAP.md 全文不到 40 行但它精确回答了社区最常问的几个问题什么正在做、什么在调研、什么明确不做。它是一份决策文档而非功能承诺书——文档开篇即声明This roadmap is not a commitment. Priorities shift.本路线图并非承诺优先级随时会变。本文将这份文档与仓库中的实际代码、构建配置与工具链相互印证逐条展开。一、路线图文档的定位为技术选型提供决策参考ROADMAP.md 的写作目的非常清晰它不是为了给外部一个画饼式的发布计划而是为了回答关于项目方向的高频问题让开发者在决定Valdi 是否适合我的项目时拥有足够的依据。文档结构分为三大块In Progress进行中Web / HTML target、bzlmod 支持Not on Our Current Roadmap不在当前路线图Swift/SwiftUI 运行时、WebSocket API、macOS Intel (x64)、Windows 开发环境Questions?反馈渠道通过 GitHub Discussion 或 issue 提交诉求。这种明确列出不做什么的做法对技术选型者尤其有价值——你可以提前预判未来几年哪些能力不会出现从而避免在错误的方向上投入。二、进行中Web / HTML 渲染器2.1 现状移动端三平台已就绪Valdi 目前已经能将组件渲染到iOS、Android 和 macOS。其工作方式详见 docs/docs/start-about.md 与 docs/docs/faq.md为开发者用 TypeScript / TSX 声明式编写视图与业务逻辑构建期由 Valdi 编译器将 TS/TSX 编译打包为.valdimodule文件代码可打包为 JS 源码、JS 字节码或直接编译为原生 C 代码运行期由 Valdi RuntimeC 核心 JavaScript 引擎 Yoga 布局引擎读取模块并在各平台创建原生视图iOS 上的UIView/UILabelAndroid 上的ViewGroup/TextView等。注意当前所有平台都有原生壳——渲染发生在宿主应用进程内的原生视图树上。2.2 目标同一个组件在浏览器中无壳渲染路线图中提到的 Web renderer 目标是直接面向 HTML/CSS 渲染让同一组件能在浏览器中渲染without a native shell无需原生壳。这意味着未来可以将同一套 UI 代码直接跑在浏览器里用于 Web 场景或跨端预览不依赖 JS 到原生桥接层而是由渲染器直接操作 DOM / CSS。2.3 可用性今天就能试但有粗糙之处路线图明确说明The web renderer is available to try today—use it at your own risk and expect rough edges.即 Web 渲染器目前已可试用但并非生产就绪使用时需自担风险并预期有粗糙的边界情况。docs/docs/faq.md 中的 Does Valdi support a web / HTML target? 一节与路线图完全一致actively in development and available to try today. Expect rough edges—its not production-ready.仓库中的 tools/valdi_web_devtools 目录即为围绕该方向搭建的配套工具链详见 tools/valdi_web_devtools/README.mdvaldi-web-devtools面向浏览器侧的入口包提供mountRoot挂载已编译的 Valdi 模块到 DOM与attachHmr接入热更新两个浏览器安全 APIwebpack 配置助手createWebpackConfig({ npmPackageName, npmScope, playgroundDir, entry, ... })帮助把导出的 Valdi 库打包进 Web playgroundvaldi_web_playgroundBazel 宏把导出库 webpack HMR dev server 集成测试脚手架组装成一个可运行的 playground 目标HMR 开发服务器hmr-server.js/hmr.js支持浏览器内热更新迭代。其 README 还强调了一个工程细节三处配置必须一致——valdi_exported_library(npm_scope, web_package_name)BUILD.bazel、valdi_web_playground(npm_package)BUILD.bazel与createWebpackConfig({npmScope, npmPackageName})webpack.config.js。编译产物中写死的require(scope/name)字符串依赖三者的对齐一旦不一致宏会在构建期fail loudly大声失败并给出指明两侧来源的错误信息。此外CLI 调试器也提供了 Web 侧能力docs/docs/command-line-references.md 中的valdi debugger支持--web-preview-url参数可启动本地浏览器调试界面并接入 Web 预览。2.4 与现有渲染架构的关系从 docs/docs/faq.md 对运行时机制的描述可以推断Web 渲染器面临的挑战与移动端一致Valdi 的 TSX 会转换为jsx.beginElement(...)/jsx.beginComponent(...)这类渲染器栈操作而非 React 式的对象 diff运行时据此以最高效的方式维护视图层级。Web 渲染器需要把这条动态渲染指令流重新映射到 DOM/CSS 上这正是其rough edges可能集中的地方——布局Yoga flexbox 到 CSS 的映射、文本测量、滚动容器与手势处理都需要在 Web 语义下重新实现。一句话建议如果你的团队打算让 Valdi 组件在浏览器中直接运行请把它当作可提前验证的预览能力而不是当前生产环境的依赖项。三、进行中bzlmod 支持3.1 背景从 WORKSPACE 到 MODULE.bazel路线图指出Valdi 目前要求使用者采用基于WORKSPACE的 Bazel 工程布局团队正在迁移到bzlmodMODULE.bazel——这是 Bazel 的现代依赖模型也是向 Bazel Central RegistryBazel 中央注册表发布模块的先决条件。迁移完成后使用者将能像消费标准 Bazel 模块一样使用 Valdi而无需手动管理WORKSPACE条目。3.2 仓库证据MODULE.bazel 已在根目录就位仓库根目录的 MODULE.bazel 已经是一个完整、可运行的 bzlmod 模块定义开头即声明module( name valdi, version 0.1, )其后是大量声明式依赖管理可作为理解 Valdi 构建依赖谱系的入口bazel_dep(...)声明对 Bazel Central Registry 上标准模块的依赖例如toolchains_llvm 1.7.0、rules_pkg 0.9.1、rules_proto 7.1.0、rules_python 1.9.0、rules_cc 0.2.20、googletest 1.17.0、rules_rust 0.64.0、rules_android 0.6.5、rules_swift 3.1.2、rules_apple 4.0.0、aspect_rules_js 2.9.2、rules_nodejs 6.7.5、boringssl、curl 8.12.0等覆盖 Android / iOS / macOS / Linux 全平台的工具链与三方库single_version_override(...)对部分模块做版本钉死如protobuf 29.3、rules_pkg 0.9.1、zlib 1.3.2并可为指定模块叠加补丁如rules_android_ndk、rules_android、rules_swiftuse_extension(...)use_repo(...)调用自定义模块扩展例如hermetic_android_sdk_extension见 bzl/hermetic_android_sdk.bzl配置api_level 36、build_tools_version 34.0.0产出androidsdkhermetic_ndk_extension见 bzl/hermetic_ndk.bzl产出androidndkswift_toolchains_extension见 bzlmod/swift_toolchains_extension.bzl注册 Linux x86_64 的 Swift 工具链valdi_compiler_repos/valdi_compiler_swift_deps暴露编译器预构建产物与 SwiftPM 依赖resvg_crate/pngquant_crate通过 rules_rust 的 crate_universe 管理 Rust 依赖用于图片解码与 PNG 压缩等register_toolchains(...)统一注册 LLVM、Android SDK/NDK、Swift、Rust 等工具链注释中明确说明consumers inherit these register_toolchains() without calling any extensions themselves——即下游使用者无需再自行调用扩展local_path_override(...)对仓库内部的子模块如android_macros→ bzl/macros、snap_macros→ bzl/valdi/snap_macros、valdi_toolchain→ bin、skia_user_config→ third-party/skia_user_config做本地路径覆盖实现库内自举。可以看到MODULE.bazel 不只是把依赖平铺出来还承载了hermetic封闭式构建的核心思路SDK、NDK、工具链全部通过扩展按需下载固定版本避免依赖宿主机ANDROID_HOME等环境变量模块注释中专门解释了为什么要给rules_android打 hermetic SDK 补丁。3.3 仓库证据registry 目录——Bazel Central Registry 的发布准备路线图说 bzlmod 是发布到 Bazel Central Registry 的前提仓库中的 registry 目录正是这项工作的落地痕迹registry/bazel_registry.jsonBazel 注册表的元数据描述文件当前mirrors为空、module_base_path为空属于初始状态registry/modules 下为每个需要重新打包/打补丁的第三方模块建了模块名/版本号/结构内含MODULE.bazel该版本模块自己的声明source.json指向源码归档的描述metadata.json模块级元数据patches/Valdi 对该模块的定制补丁如rules_android_hermetic_sdk.patch、rules_android_module_bzl.patch、rules_swift.patch、toolchains_llvm.patch、rules_kotlin.patch、rules_nodejs.patch、websocketpp.patch。目前 registry 覆盖的模块包括rules_android、rules_android_ndk、rules_kotlin含 1.9.0 与 2.3.10 两个版本、rules_nodejs、rules_swift、toolchains_llvm、websocketpp。这些打了补丁的官方模块是 Valdi 在 bzlmod 世界中保持 hermetic 构建的关键——它们既要跟随上游版本又要带上 Valdi 的定制改动。从这些文件的存在可以推断Valdi 的 bzlmod 迁移不只是改一个构建文件而是围绕第三方模块的补丁治理、版本钉死与扩展封装建立了一整套配套机制。3.4 对使用者的影响迁移完成后下游项目的体验将从在WORKSPACE里手工写http_archive/git_repository拉取 Valdi 及一堆传递依赖变成# MODULE.bazel示意发布后的最终用法 bazel_dep(name valdi, version 版本)即标准 Bazel 模块的消费方式依赖解析、版本选择、工具链注册均由 Bazel 的模块系统接管。不过需要说明当前 MODULE.bazel 仍以local_path_override引用了大量仓库内部模块且valdi版本号为0.1尚未正式发布到 Bazel Central Registry——这正是路线图中进行中的状态。四、明确不做一Swift / SwiftUI 运行时4.1 事实路线图明确iOS 运行时当前是 Objective-C 实现没有计划用 Swift 重写也不会提供 SwiftUI interop 层。4.2 替代方案Polyglot 模块这并不意味着不能用 Swift。路线图和 docs/docs/faq.md 都指向同一个解法Polyglot 模块——让你用 Swift以及 Kotlin、C、Objective-C写 Valdi 能调用的代码覆盖绝大多数集成需求。docs/docs/native-polyglot.md 给出了完整实操流程要点如下TypeScript 定义在模块的.d.ts文件中用ExportModule注解声明 API例如/* ExportModule */ export const DEFAULT_DELIMITER: string; export function join(components: string[], delimiter: string): string;编译器会据此生成 Objective-C、Swift、Kotlin 等语言的绑定。Bazel 侧接线valdi_module规则导出三个属性分别挂接不同平台的原生实现android_depsAndroid 构建时引入的android_libraryJVM 语言实现ios_depsiOS 构建时引入的apple_library/cc_libraryObjective-C / Swift 等原生实现native_deps全平台iOS/Android/桌面引入的cc_libraryC 跨平台实现。平台实现iOS 侧写 Objective-C 实现类实现生成协议并在工厂类中用VALDI_REGISTER_MODULE()注册、onLoadModule懒加载返回模块实例Android 侧写 Kotlin 实现类用RegisterValdiModule注解须经valdi_android_library规则编译构建期会处理注解注册C 侧因编译器暂不支持 C 代码生成绑定需手写通过RegisterModuleFactory::registerTypedMyJoinerModule()注册。运行时行为当 TypeScript 首次 import 该.d.ts文件时对应平台的工厂onLoadModule被调用返回的实例即成为该模块的底层实现。换句话说运行时必须是 Swift不是 Valdi 的承诺但你的 Swift 代码能被 Valdi 调用是现成的能力。五、明确不做二WebSocket API路线图明确Valdi 不暴露 WebSocket API。官方给出的 workaround 是在原生代码中实现 WebSocket 处理再通过 Polyglot 模块暴露给 Valdi 使用暂无在运行时增加一等公民 WebSocket 支持的计划。从仓库现状看MODULE.bazel 中虽引入了websocketpp 0.8.2.bcr.3并打了fix_ios_lrt.patch以及作为 HTTP 传输层的curl但这些属于底层网络能力服务于运行时自身的通信需求并不等于面向 TS 业务层的一等 WebSocket API。业务侧需要长连接时正确路径是业务 TS 代码 │ import ▼ Polyglot 模块TS 定义 原生实现 │ ▼ 原生 WebSocket 客户端iOS: NSURLSessionWebSocket / Android: OkHttp 等这也与 Valdi打破 Web 标准以换取移动端性能与工程效率的设计哲学一脉相承见 docs/docs/faq.md 中对 React Native 差异的讨论——网络能力优先以原生形态提供而不是在 JS 层重建一套。六、明确不做三macOS Intelx64支持路线图明确macOS 开发环境与目标平台仅支持 Apple Siliconarm64没有添加 x64 支持的计划。这意味着在 Intel Mac 上进行 Valdi 开发不可行以 macOS 为目标平台构建的产物仅面向 arm64若团队里还有 Intel Mac需要将其排除在 Valdi 开发环境之外或通过远程 arm64 构建机。仓库的 MODULE.bazel 也侧面印证了这一点python.single_version_platform_override仅针对aarch64-apple-darwin打补丁Swift 工具链扩展bzlmod/swift_toolchains_extension.bzl注册的是 Linux x86_64 工具链Rust 的supported_platform_triples中 Apple 平台只包含aarch64-apple-darwin/aarch64-apple-ios等 arm64 变体。可以推断官方构建矩阵已全面以 arm64 为主。七、明确不做四Windows 开发环境路线图明确Valdi 不支持 Windows 作为开发宿主操作系统host OS。这与 Valdi 的工具链现实相符编译器由 Swift 编写compiler/compilerBazel 工具链与脚本大量面向 macOS/Linux见 scripts 下的macos_dev_setup.sh、linux_dev_setup.sh等Android 构建依赖 hermetic SDK/NDK 与 LLVM 工具链。Windows 既不在构建矩阵中也没有文档化的支持路径。若你的团队全员使用 Windows 开发机Valdi 目前不适用需要借助 CI 上的 Linux/macOS 执行环境。八、综合判断这些边界如何影响你的选型将路线图的进行中与明确不做合起来可以得到一张清晰的决策表关注点Valdi 现状决策含义移动端iOS / AndroidUI已支持生产可用的核心场景主战场macOS 桌面目标已支持仅 arm64Apple Silicon 团队可用Web / 浏览器渲染开发中可试用非生产就绪可提前验证勿作生产依赖依赖管理WORKSPACE → bzlmod 迁移中MODULE.bazel 已就位未来可标准模块方式消费Swift 集成运行时仍是 Objective-C但 Polyglot 模块可调 Swift 代码原生能力用 native-polyglot.md 补齐WebSocket无一等 API需原生实现 Polyglot 暴露长连接场景需自建Intel Mac / Windows明确不支持开发环境需 arm64 Mac 或 Linux需要强调的两点路线图不是承诺。文档开头就写明优先级会变化若某项能力对你至关重要官方建议通过 GitHub Discussion 说明原因——社区的反馈会影响优先级的排序。仓库状态以当前代码为准。本文对进行中/未提供的判断基于仓库当前内容ROADMAP.md、MODULE.bazel、registry、docs/docs/faq.md 等能力与版本边界随时可能演进落地前请以最新仓库为准。九、反馈与参与如果你对路线图中的任何条目有诉求想加速 Web 渲染器、希望重新评估 x64/Windows、或推动某能力进入计划官方渠道是仓库的 Discussions 与 Issues。结合本文梳理的边界带着明确的使用场景去沟通会让你的诉求更容易被评估。参考与深入阅读均位于当前仓库路线图原文ROADMAP.md常见问题与定位docs/docs/faq.md框架概述与架构分层docs/docs/start-about.mdPolyglot 模块完整教程Swift/Kotlin/ObjC/C 实现docs/docs/native-polyglot.mdbzlmod 模块声明MODULE.bazel、扩展示例 bzlmod/swift_toolchains_extension.bzlBazel Central Registry 发布准备registry/bazel_registry.json 与 registry/modulesWeb 方向配套工具链tools/valdi_web_devtools/README.mdCLI 调试器的 Web 预览参数docs/docs/command-line-references.md【免费下载链接】ValdiValdi is a cross-platform UI framework that delivers native performance without sacrificing developer velocity.项目地址: https://gitcode.com/gh_mirrors/val/Valdi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考