Windmill windmill-parser-wasm 开发指南构建与调试多语言脚本解析的 WASM 包【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmillWindmill 的浏览器端能力编辑器实时推断脚本入参签名、解析 import、识别资源引用依赖一组由 Rust 编写并编译为 WebAssembly 的解析器。本文以 windmill-parser-wasm 开发文档 为主线覆盖从安装 wasm-pack / 进入 Nix 开发 Shell、执行 release 构建、本地按语言调试到在 Docker 开发环境中手动挂载解析器的完整流程并结合 Cargo.toml、lib.rs 与 docker/dev.nu 等源码说明每个步骤背后的实现细节。组件定位为什么需要 WASM 版的解析器从源码结构看Windmill 将各语言TypeScript、Python、Go、Rust、SQL、YAML/Ansible、Bash、PowerShell、C#、Java、Ruby、R、Nushell、GraphQL、PHP 等的解析逻辑拆分在 backend/parsers/ 下的独立 crate 中例如 windmill-parser-ts、windmill-parser-py、windmill-parser-sql。windmill-parser-wasm 则是把这些 crate 聚合编译为浏览器可加载的cdylib见 Cargo.toml 中crate-type [cdylib]的入口。lib.rs 中通过#[wasm_bindgen]暴露了各语言的解析入口且全部按 feature 条件编译例如#[cfg(feature ts-parser)] #[wasm_bindgen] pub fn parse_deno(code: str, main_override: OptionString) - String { wrap_sig(windmill_parser_ts::parse_deno_signature( code, false, false, main_override, )) }绝大多数导出函数返回序列化为 JSON 的MainArgSignature脚本main函数的参数签名失败时统一返回{type: Invalid}另有parse_ts_imports/parse_ts_relative_imports解析 TypeScript 依赖、parse_assets_sql/ts/py解析资产asset中引用的其他脚本与资源、parse_workflow_as_code解析 WAC 工作流。文件末尾的注释// for related places search: ADD_NEW_LANG是维护者留下的扩展标记新增语言时需要检索该关键字同步修改各处feature、导出函数、前端依赖等。前置条件安装 wasm-pack 或进入 Nix 开发 Shell文档给出的两条路径分别是# 全局安装 wasm-pack cargo install wasm-pack或者进入仓库提供的 Nix 开发 Shellnix develop ../../#wasm对应 flake.nix 中定义的devShells.wasm该 Shell 通过 rustup 安装了wasm32-unknown-unknown与wasm32-unknown-emscripten两个目标并内置了wasm-pack。其中有一行显式注释# DO NOT REMOVE - if absent, breaks wasm builds on NixOS.说明该 Shell 中存在针对 NixOS 下 WASM 构建的关键环境修正在 NixOS 上做本地构建时建议优先使用该 Shell 而非裸装工具链。Release 构建核心构建命令为wasm-pack build --release --target web执行前需要理解 Cargo.toml 中的几个关键设计独立的 workspace该 crate 被刻意排除在 backend/Cargo.toml 的父 workspace 之外父文件中exclude [...]因为它使用了 nightly-only 特性cargo-features [panic-immediate-abort] [unstable] build-std [std, panic_abort] [profile.release] panic immediate-abort[unstable] build-std要求 nightly 工具链重新编译标准库panic immediate-abort配合 wasm-pack 可显著减小产物体积。因此该目录自带[workspace] members [.]声明自己的 workspace而其余windmill-parser-*crate 仍通过 path 依赖引用、继续使用父 workspace。按语言裁剪产物每个语言对应一个可选 feature例如ts-parser、py-parser、go-parser、sql-parser、nu-parser、asset-parser、wac-parser等。按语言分别出包见后文 publish 脚本中的pkg-ts、pkg-py等目录名意味着构建时只启用所需 feature避免前端加载无关语言的全量解析器。依赖细节wasm-bindgen被锁定为0.2.103getrandom启用jsfeature同时引入 0.3 版本的getrandom3带wasm_jsfeature以满足 wasm32-unknown-unknown 目标下 rand 的随机数需求——这些是 WASM 目标特有的适配点改动依赖时需注意。本地开发用 dev.nu 构建指定语言文档推荐的日常开发入口是./dev.nu languagedev.nu 实际做三件事def main [ lang: string # Example: nu ] { ./build.nu $lang --no-opt do { cd ../../../frontend; npm install ../backend/parsers/windmill-parser-wasm/pkg-($lang) } do { cd ../../../cli; bun install ../backend/parsers/windmill-parser-wasm/pkg-($lang) } }即以非优化debug模式构建指定语言的 wasm 包--no-opt编译更快产物落在pkg-lang/目录然后分别执行npm install与bun install将该目录作为本地路径依赖安装进 frontend 和 cli 两个消费方。这样一次命令即可同时刷新前端与 CLI 的解析器适合在改动某个语言解析逻辑后快速验证编辑器行为。手动在开发环境中使用构建产物如果不使用dev.nu也可以手动把 release 产物接入前端。文档的步骤是# 在 frontend/ 目录执行 npm install ../backend/parsers/windmill-parser-wasm/pkg并特别提醒提交前不要还原 package.jsonMake sure to not reset the package.json before commiting——因为该依赖是以本地目录路径形式写入的回退 package.json 会使构建产物失效。补充两个仓库中的事实依据frontend/package.json 中已经声明了若干按语言拆分的 npm 包如windmill-parser-wasm-py、windmill-parser-wasm-go、windmill-parser-wasm-asset等说明生产构建使用发布到 registry 的固定版本包而本地联调时替换为路径依赖windmill-parser-wasm/pkg/ 下还提交了预构建产物windmill_parser_wasm.js、windmill_parser_wasm_bg.wasm及其类型声明pkg/package.json 声明files字段只包含这三份文件供直接npm install 目录使用。用 Docker 测试当需要在接近部署形态的环境中验证时文档给出从仓库根目录执行sudo docker/dev.nu up --features feature1,feature2 --wasm-pkg language例如测试 Nushellsudo docker/dev.nu up --features static_frontend,nu --wasm-pkg nu从 docker/dev.nu 的源码看--wasm-pkg参数的作用是动态改写主 Dockerfile将标记行# -- MACRO-SPREAD-WASM-PARSER-DEV-ONLY -- #替换为COPY ./backend/parsers/windmill-parser-wasm/pkg-($wasm_pkg) ./node_modules/windmill-parser-wasm-($wasm_pkg)也就是说构建镜像时会把本地构建好的pkg-lang目录直接复制进镜像的node_modules覆盖对应语言解析器的发布版本从而让容器内运行的前端使用你刚构建的 wasm 包。--features则控制镜像启用的后端 feature示例中的static_frontend,nu表示静态前端 Nushell 支持。测试wasm-bindgen-test[dev-dependencies]中引入了wasm-bindgen-testtests/wasm.rs 使用#[wasm_bindgen_test]编写针对 wasm 目标的测试。例如test_parse_deno_sig验证parse_deno_signature对可选参数、默认值、wmill.Resourcepostgres、Base64、字面量联合类型test | test2、嵌套对象等类型注解的解析结果与预期的MainArgSignature完全一致——这类断言是各语言解析行为回归的基准。另外deno.json 定义了wasmbuild任务deno run -A jsr:deno/wasmbuild0.19.0说明除 wasm-pack 外Deno 生态的 wasmbuild 工具链也被用于构建/测试流程可在 Deno 环境如 Nushell 工作流中作为备选。发布按语言独立发 npm 包开发完成后的发布由 publish-pkgs.sh 完成脚本依次进入pkg-ts、pkg-regex、pkg-py、pkg-go、pkg-php、pkg-rust、pkg-yaml、pkg-csharp、pkg-nu、pkg-java、pkg-asset、pkg-py-imports、pkg-wac目录并执行npm publish。这解释了前端依赖中各windmill-parser-wasm-*包版本号彼此独立的现象——它们各自独立演进、独立发布。小结完整开发回路场景命令依据安装工具链cargo install wasm-pack或nix develop ../../#wasmREADME_DEV.md、flake.nixRelease 构建wasm-pack build --release --target webREADME_DEV.md本地按语言调试./dev.nu languagedebug 构建并装进 frontend clidev.nu手动接入前端npm install ../backend/parsers/windmill-parser-wasm/pkg勿回退 package.jsonREADME_DEV.mdDocker 环境验证sudo docker/dev.nu up --features static_frontend,nu --wasm-pkg nudocker/dev.nu测试#[wasm_bindgen_test]用例tests/wasm.rs发布./publish-pkgs.shpublish-pkgs.sh需要注意的前提与限制该 crate 依赖 nightly-only 的build-std与panic-immediate-abort必须使用 nightly 工具链Nix 的#wasmShell 已包含它独立于 backend 父 workspace不能在 backend 目录内用cargo build -p windmill-parser-wasm的常规方式构建构建产物按语言分 feature出包时按需启用对应 feature 以控制产物体积。【免费下载链接】windmillOpen-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.项目地址: https://gitcode.com/GitHub_Trending/wi/windmill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考