WAMR-IDE VSCode 扩展贡献指南从 PR 流程到 Prettier/ESLint 工程化规范【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bitWAMR-IDE 是 WebAssembly Micro RuntimeWAMR项目提供的一款 VSCode 集成开发环境扩展用于 WebAssembly 工程的创建、编译、运行与源码级调试。本文以仓库内 WAMR-IDE 扩展的 CONTRIBUTING.md 为骨架系统讲解向该扩展提交代码的完整流程、Prettier 与 ESLint 双工具链的工程化规范并结合扩展的package.json、配置文件与源码给出可直接落地的操作命令。读完后你将能够独立完成一次从环境搭建、编码、格式检查、静态检查到提交 Pull Request 的完整贡献闭环。项目背景你将要贡献的代码库本文对应的代码库是 WAMR 仓库中test-tools/wamr-ide/VSCode-Extension目录下的 VSCode 扩展package.json中name为wamridedisplayName为WAMR-IDE。从 package.json 可以确认扩展语言TypeScriptmain指向编译产物./out/extension.js编译命令为tsc -p ./运行环境要求VSCode^1.59.0、Node.js16.0.0主要能力通过wamride.newProject、wamride.build、wamride.run、wamride.debug等命令完成 WASM 工程的创建、构建、运行和调试扩展激活时机onStartupFinished即在 VSCode 启动完成后自动激活。扩展的代码组织可以从 src/extension.ts 一窥全貌activate()函数中注册了wasm类型的 Task Providersrc/taskProvider.ts、wamr-debug类型的调试配置提供器src/debugConfigurationProvider.ts并通过viewsWelcome在活动栏提供 “New project / Open project / Build / Run / Debug” 的快捷入口。理解这一点有助于你判断自己的改动落在哪个模块。Pull Request 提交流程按照 CONTRIBUTING.md 的约定提交一份改动需要依次完成以下三步确保代码符合编码规范代码风格必须与下文 “编码规范” 一节保持一致这是评审通过的前提先创建 Issue在项目仓库的 Issues 页面描述该 PR 要修复的 Bug 或打算实现的功能让改动意图先被记录和讨论提交 Pull Request将改动以 Pull Request 的形式合并进main 分支。这一流程保证了每一次合并都有明确的 Issue 跟踪、规范的代码风格和清晰的变更来源也是评审者能够快速审查的关键。编码规范一Prettier 统一格式代码库统一使用Prettier进行格式化且仓库内已配置好 .prettierrc.json。该配置文件明确了全库统一的格式化口径{ printWidth: 80, tabWidth: 4, useTabs: false, semi: true, singleQuote: true, trailingComma: es5, bracketSpacing: true, jsxBracketSameLine: false, arrowParens: avoid, proseWrap: always }核心约定解读printWidth: 80单行代码最长 80 个字符超长自动换行tabWidth: 4/useTabs: false缩进为 4 个空格不使用 Tabsemi: true语句末尾强制分号singleQuote: true字符串统一使用单引号trailingComma: es5仅在 ES5 允许的位置对象、数组等追加尾逗号arrowParens: avoid单参数箭头函数省略括号。两种格式化工作方式原文档给出了两种使用方式二者任选其一即可方式一VSCode 编辑器内格式化在 VSCode 中开启Format on Save保存时自动格式化配置配合扩展开发环境即可在编码过程中实时套用上述规则无需手动干预。方式二终端命令格式化在扩展目录下执行package.json中预置的两个 npm scripts见 package.json# 仅检查格式是否符合规范只读不修改文件 npm run prettier-format-check # 直接对源码套用格式化 npm run prettier-format-apply从package.json的实现可以看到这两个脚本分别等价于# prettier-format-check prettier --config .prettierrc.json src/**/*.ts --check # prettier-format-apply prettier --config .prettierrc.json src/**/*.ts --write即它们只针对src/目录下的 TypeScript 文件生效。仓库使用 Prettier2.5.1版本见devDependencies建议本地安装版本与之一致避免格式化结果漂移。编码规范二ESLint 静态检查除了格式统一代码库还使用ESLint作为 linter配置文件为 .eslintrc.json。其配置要点如下{ root: true, parser: typescript-eslint/parser, extends: [plugin:typescript-eslint/recommended], plugins: [typescript-eslint], rules: { typescript-eslint/naming-convention: warn, typescript-eslint/semi: warn, curly: warn, eqeqeq: warn, no-throw-literal: warn, semi: off }, ignorePatterns: [out, dist, **/*.d.ts] }采用typescript-eslint解析器与推荐规则集面向 TypeScript 代码做类型感知的静态检查额外启用的规则包括命名约定naming-convention、语句分号semi、强制花括号curly、强制全等比较eqeqeq、禁止抛出非 Error 对象no-throw-literal级别均为warn编译产物目录out、dist以及.d.ts声明文件被排除在检查范围之外。提交前的 lint 检查原文档明确建议在提交前运行npm run lint并修复其中暴露的错误与警告。该脚本在package.json中定义为lint: eslint src --ext ts, lint-fix: eslint --fix src --ext tsnpm run lint对src/下所有.ts文件做只读检查npm run lint-fix自动修复可自动修复的问题如分号、全等比较等再手动处理剩余告警。需要说明的是package.json中pretest钩子为npm run compile npm run lint也就是说测试运行前会强制先编译并 lint任何 lint 失败都会阻断测试链路因此养成 “提交前 lint” 的习惯可以避免在 CI 阶段才发现问题。从零搭建开发与调试环境CONTRIBUTING.md侧重规范与流程而扩展自身的 README.md 补充了贡献者最关心的本地开发调试步骤二者结合才能形成完整的贡献工作流用 VSCode 打开扩展目录File - Open Folder选择VSCode-Extension目录即lib/wasm-micro-runtime-WAMR-2.4.1/test-tools/wamr-ide/VSCode-Extension安装依赖在终端执行npm install安装package.json中声明的全部依赖与开发依赖启动扩展宿主按F5或按CtrlShiftD切换到 “运行和调试Run and Debug” 面板点击Run ExtensionVSCode 会打开一个新的扩展开发宿主窗口在其中即可实时调试扩展代码。调试环境的编译链路由package.json的 scripts 支撑vscode:prepublish: npm run compile, compile: tsc -p ./, watch: tsc -watch -p ./其中watch模式tsc -watch可在修改源码后自动增量编译到out/配合 F5 的自动重载可以显著缩短开发迭代周期。注意 tsconfig.json 开启了strict: true严格类型检查、sourceMap: true生成源码映射前者保证了类型安全后者保证了断点调试能正确映射回 TypeScript 源码。运行集成测试验证改动扩展内置了一套基于vscode/test-electron的集成测试用于在真实 VSCode 环境中验证扩展行为。入口脚本为 src/test/runTest.ts它会以扩展 manifestpackage.json所在目录作为--extensionDevelopmentPath以src/test/suite/index作为测试入口--extensionTestsPath自动下载对应版本的 VSCode、解压并以临时目录--user-data-dir运行集成测试。测试用例位于 src/test/suite/extension.test.ts配套的suite/utils.ts与suite/index.ts提供测试工具与 Mocha 运行器配置。执行方式npm test由于pretest钩子会先执行npm run compile npm run lint一次npm test实际上会按编译 → lint → 集成测试的顺序验证你的改动是提交 PR 前最完整的本地自检手段。从源码视角理解改动影响面为了让 PR 更容易被评审者接受建议提交前结合源码确认改动的影响面命令与 UI 入口所有wamride.*命令及其在活动栏、欢迎视图、右键菜单中的展示均声明于 package.json 的contributes段新增命令时必须同步注册到 src/extension.ts 的context.subscriptions第 764-774 行附近并加入package.json的activationEvents否则命令可能无法触发构建 / 运行 / 调试任务扩展通过 Task Provider 注册wasm类型任务Build、Run、Debug、Destroy构建时还依赖 Docker 镜像与resource/scripts/下的build.sh/build.bat等脚本见 src/extension.ts修改构建逻辑时需同时考虑 Windows.bat与 Linux/macOS.sh双平台脚本工程配置文件.wamr/compilation_config.json与.wamr/project.cmake由扩展在构建时动态生成见 src/extension.ts改动文件收集、include path 或导出符号相关逻辑时需同步关注该生成流程。提交前检查清单综合CONTRIBUTING.md、README.md与package.json中的工程化约束一个可被顺利合并的 PR 应满足检查项命令 / 工具依据格式合规npm run prettier-format-checkCONTRIBUTING.md package.json静态检查无错误npm run lintCONTRIBUTING.md package.json编译通过npm run compile或npm run watchpackage.json集成测试通过npm testpackage.json有对应 Issue 且 PR 指向 main 分支仓库 Issues / Pull requests 页面CONTRIBUTING.md按照 “创建 Issue → 本地开发调试 → 格式化与 lint 自检 → 编译与测试 → 提交 PR 到 main 分支” 的顺序推进你的改动就能与 WAMR-IDE 扩展既有的工程化体系无缝衔接从而获得更快的评审与合并。【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考