Conversation
Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
审查者指南（Reviewer's Guide）此变更添加了一个自动化的 GitHub Actions 工作流，用于构建并发布 VS Code 扩展的 VSIX 构件；更新了安装文档和故障排查指南；提升了扩展版本；微调了测试与翻译预期；并为 GitHub Actions 更新分组以及扩展的 npm 依赖的每周更新配置了 Dependabot。 新增 VS Code 扩展构建 GitHub Actions 工作流的时序图sequenceDiagram
actor Developer
participant GitHub
participant Build_Extension_Workflow as Build_Extension_Workflow
participant Actions_Artifact_Storage as Actions_Artifact_Storage
participant Pull_Request as Pull_Request
Developer->>GitHub: push / pull_request / schedule / workflow_dispatch
GitHub->>Build_Extension_Workflow: trigger build-vscode-extension.yml
Build_Extension_Workflow->>Build_Extension_Workflow: actions/checkout@v4
Build_Extension_Workflow->>Build_Extension_Workflow: actions/setup-node@v4
Build_Extension_Workflow->>Build_Extension_Workflow: npm ci
Build_Extension_Workflow->>Build_Extension_Workflow: npx @vscode/vsce package
Build_Extension_Workflow->>Actions_Artifact_Storage: actions/upload-artifact@v7 (github-chinese-extension.vsix)
alt [github.event_name == pull_request]
Build_Extension_Workflow->>Pull_Request: actions/github-script@v7 createComment / updateComment
end
Build_Extension_Workflow->>GitHub: write GITHUB_STEP_SUMMARY
文件级变更
提示与命令与 Sourcery 交互
自定义你的体验访问你的 仪表盘 以：
获取帮助Original review guide in EnglishReviewer's GuideAdds an automated GitHub Actions workflow to build and publish a VSIX artifact for the VS Code extension, updates installation docs and troubleshooting guidance, bumps the extension version, tweaks tests and translation expectations, and configures Dependabot for grouped GitHub Actions and weekly npm updates for the extension. Sequence diagram for the new VS Code extension build GitHub Actions workflowsequenceDiagram
actor Developer
participant GitHub
participant Build_Extension_Workflow as Build_Extension_Workflow
participant Actions_Artifact_Storage as Actions_Artifact_Storage
participant Pull_Request as Pull_Request
Developer->>GitHub: push / pull_request / schedule / workflow_dispatch
GitHub->>Build_Extension_Workflow: trigger build-vscode-extension.yml
Build_Extension_Workflow->>Build_Extension_Workflow: actions/checkout@v4
Build_Extension_Workflow->>Build_Extension_Workflow: actions/setup-node@v4
Build_Extension_Workflow->>Build_Extension_Workflow: npm ci
Build_Extension_Workflow->>Build_Extension_Workflow: npx @vscode/vsce package
Build_Extension_Workflow->>Actions_Artifact_Storage: actions/upload-artifact@v7 (github-chinese-extension.vsix)
alt [github.event_name == pull_request]
Build_Extension_Workflow->>Pull_Request: actions/github-script@v7 createComment / updateComment
end
Build_Extension_Workflow->>GitHub: write GITHUB_STEP_SUMMARY
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - 我发现了 5 个问题，并留下了一些总体反馈：
- README 中的工作流链接指向
actions/workflows/build-vscode-extension，但实际的 Actions URL 通常会包含.yml后缀（例如build-vscode-extension.yml），建议更新该链接以避免 404。 - Actions 工作流使用了
node-version: '24'，这已经超出了当前的 LTS 版本；建议固定到最新的 LTS（例如 22），或者在文档中说明为什么需要 24，以避免当 GitHub Runner 镜像更新时出现意外的 CI 中断。
给 AI Agent 的提示词
Please address the comments from this code review:
## Overall Comments
- The workflow link in the README points to `actions/workflows/build-vscode-extension` but the actual Actions URL typically includes the `.yml` suffix (e.g. `build-vscode-extension.yml`), so consider updating the link to avoid 404s.
- The Actions workflow uses `node-version: '24'`, which is ahead of the current LTS; consider pinning to the latest LTS (e.g. 22) or documenting why 24 is required to avoid unexpected CI breakage when GitHub’s runner image changes.
## Individual Comments
### Comment 1
<location path=".github/workflows/build-vscode-extension.yml" line_range="33-36" />
<code_context>
+ - name: 检出代码
+ uses: actions/checkout@v4
+
+ - name: 设置 Node.js 环境
+ uses: actions/setup-node@v4
+ with:
+ node-version: '24'
+ cache: 'npm'
+ cache-dependency-path: 'vscode-extension/package-lock.json'
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider pinning Node to an LTS version or a more explicit version range for build stability
`node-version: '24'` will always use the latest 24.x, which isn’t an LTS line and can introduce breaking changes into CI over time. For more stable builds, consider pinning to the current LTS (e.g. `22`) or to an exact minor/patch. If you intentionally require 24.x, please document that and optionally run a small version matrix (e.g. `20`/`22`/`24`) to detect incompatibilities early.
Suggested implementation:
```
- name: 设置 Node.js 环境（使用 LTS 版本以提高构建稳定性）
uses: actions/setup-node@v4
with:
# 使用当前 Node.js LTS 版本，避免非 LTS 版本在次要更新中引入破坏性变更
node-version: '22.x'
cache: 'npm'
cache-dependency-path: 'vscode-extension/package-lock.json'
```
If you want to go further with the suggestion and run a small version matrix (e.g. `20`/`22`/`24`), you would:
1. Introduce a `strategy.matrix.node-version` section at the job level with the desired versions.
2. Replace this `node-version: '22.x'` with `node-version: ${{ matrix.node-version }}`.
3. Optionally extend the job to run compatibility checks or tests across all matrix entries.
</issue_to_address>
### Comment 2
<location path=".github/workflows/build-vscode-extension.yml" line_range="40-43" />
<code_context>
+ cache: 'npm'
+ cache-dependency-path: 'vscode-extension/package-lock.json'
+
+ - name: 进入插件目录并安装依赖
+ run: |
+ cd vscode-extension
+ npm install
+
+ - name: 打包 VSIX
</code_context>
<issue_to_address>
**suggestion (performance):** Using `npm ci` instead of `npm install` would make builds more reproducible and faster
Given you’re already caching based on `package-lock.json`, switching this step to `npm ci` will better enforce the lockfile (failing on drift) and usually install faster, leading to more deterministic and efficient CI runs.
```suggestion
- name: 进入插件目录并安装依赖
run: |
cd vscode-extension
npm ci
```
</issue_to_address>
### Comment 3
<location path=".github/workflows/build-vscode-extension.yml" line_range="45-52" />
<code_context>
+ cd vscode-extension
+ npm install
+
+ - name: 打包 VSIX
+ id: package
+ run: |
+ cd vscode-extension
+ npx @vscode/vsce package
+ VSIX_FILE=$(ls *.vsix | head -n 1)
+ echo "artifact_name=$VSIX_FILE" >> $GITHUB_OUTPUT
+ echo "vsix_path=vscode-extension/$VSIX_FILE" >> $GITHUB_OUTPUT
</code_context>
<issue_to_address>
**suggestion:** The VSIX file detection relies on `ls` and assumes a single match, which could be fragile
This logic depends on shell globbing and on there being exactly one `.vsix` file, so if multiple packages are present you may upload the wrong artifact. Consider making the filename deterministic by cleaning the directory first, using `vsce package -o <expected-name>.vsix`, or constraining the glob to a more specific pattern (e.g. including version).
```suggestion
- name: 打包 VSIX
id: package
run: |
cd vscode-extension
# 清理旧的 VSIX 文件，避免上传历史构件
rm -f ./*.vsix
# 使用 package.json 中的 name 和 version 生成确定性的文件名
PKG_NAME=$(node -p "require('./package.json').name")
PKG_VERSION=$(node -p "require('./package.json').version")
VSIX_FILE="${PKG_NAME}-${PKG_VERSION}.vsix"
# 以指定的文件名打包 VSIX，避免依赖 ls 和通配符
npx @vscode/vsce package -o "$VSIX_FILE"
echo "artifact_name=$VSIX_FILE" >> $GITHUB_OUTPUT
echo "vsix_path=vscode-extension/$VSIX_FILE" >> $GITHUB_OUTPUT
```
</issue_to_address>
### Comment 4
<location path=".github/workflows/build-vscode-extension.yml" line_range="60-66" />
<code_context>
+ EXPIRY_DATE=$(date -u -d "+5 days" '+%Y-%m-%d %H:%M UTC')
+ echo "expires_at=$EXPIRY_DATE" >> $GITHUB_OUTPUT
+
+ - name: 上传构件
+ uses: actions/upload-artifact@v7
+ with:
+ name: github-chinese-extension
+ path: vscode-extension/*.vsix
+ retention-days: 5
+ archive: false
</code_context>
<issue_to_address>
**suggestion:** Align artifact upload path with the computed VSIX path/output for clarity and consistency
Using `path: vscode-extension/*.vsix` while also computing `vsix_path`/`artifact_name` can upload multiple VSIX files if more than one exists, and may not match the artifact referenced in the PR comment. Please switch the upload path to `${{ steps.package.outputs.vsix_path }}` so the uploaded artifact is guaranteed to be the same one referenced elsewhere.
```suggestion
- name: 上传构件
uses: actions/upload-artifact@v7
with:
name: github-chinese-extension
path: ${{ steps.package.outputs.vsix_path }}
retention-days: 5
archive: false
```
</issue_to_address>
### Comment 5
<location path="vscode-extension/README.md" line_range="75" />
<code_context>
+```shell
+git clone https://github.com/maboloshi/github-chinese.git # 克隆仓库
+
+# 若你的网络环境无法访问 Github 克隆仓库，请自行寻找加速器等解决
+
+cd github-chinese/vscode-extension # 进入插件目录
</code_context>
<issue_to_address>
**issue (typo):** Correct “Github” to the proper capitalization “GitHub”.
Use the official capitalization “GitHub” here for consistency with the rest of the document.
```suggestion
# 若你的网络环境无法访问 GitHub 克隆仓库，请自行寻找加速器等解决
```
</issue_to_address>帮我变得更有用！请在每条评论上点 👍 或 👎，我会根据你的反馈改进后续的 Review。
Original comment in English
Hey - I've found 5 issues, and left some high level feedback:
- The workflow link in the README points to
actions/workflows/build-vscode-extensionbut the actual Actions URL typically includes the.ymlsuffix (e.g.build-vscode-extension.yml), so consider updating the link to avoid 404s. - The Actions workflow uses
node-version: '24', which is ahead of the current LTS; consider pinning to the latest LTS (e.g. 22) or documenting why 24 is required to avoid unexpected CI breakage when GitHub’s runner image changes.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The workflow link in the README points to `actions/workflows/build-vscode-extension` but the actual Actions URL typically includes the `.yml` suffix (e.g. `build-vscode-extension.yml`), so consider updating the link to avoid 404s.
- The Actions workflow uses `node-version: '24'`, which is ahead of the current LTS; consider pinning to the latest LTS (e.g. 22) or documenting why 24 is required to avoid unexpected CI breakage when GitHub’s runner image changes.
## Individual Comments
### Comment 1
<location path=".github/workflows/build-vscode-extension.yml" line_range="33-36" />
<code_context>
+ - name: 检出代码
+ uses: actions/checkout@v4
+
+ - name: 设置 Node.js 环境
+ uses: actions/setup-node@v4
+ with:
+ node-version: '24'
+ cache: 'npm'
+ cache-dependency-path: 'vscode-extension/package-lock.json'
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider pinning Node to an LTS version or a more explicit version range for build stability
`node-version: '24'` will always use the latest 24.x, which isn’t an LTS line and can introduce breaking changes into CI over time. For more stable builds, consider pinning to the current LTS (e.g. `22`) or to an exact minor/patch. If you intentionally require 24.x, please document that and optionally run a small version matrix (e.g. `20`/`22`/`24`) to detect incompatibilities early.
Suggested implementation:
```
- name: 设置 Node.js 环境（使用 LTS 版本以提高构建稳定性）
uses: actions/setup-node@v4
with:
# 使用当前 Node.js LTS 版本，避免非 LTS 版本在次要更新中引入破坏性变更
node-version: '22.x'
cache: 'npm'
cache-dependency-path: 'vscode-extension/package-lock.json'
```
If you want to go further with the suggestion and run a small version matrix (e.g. `20`/`22`/`24`), you would:
1. Introduce a `strategy.matrix.node-version` section at the job level with the desired versions.
2. Replace this `node-version: '22.x'` with `node-version: ${{ matrix.node-version }}`.
3. Optionally extend the job to run compatibility checks or tests across all matrix entries.
</issue_to_address>
### Comment 2
<location path=".github/workflows/build-vscode-extension.yml" line_range="40-43" />
<code_context>
+ cache: 'npm'
+ cache-dependency-path: 'vscode-extension/package-lock.json'
+
+ - name: 进入插件目录并安装依赖
+ run: |
+ cd vscode-extension
+ npm install
+
+ - name: 打包 VSIX
</code_context>
<issue_to_address>
**suggestion (performance):** Using `npm ci` instead of `npm install` would make builds more reproducible and faster
Given you’re already caching based on `package-lock.json`, switching this step to `npm ci` will better enforce the lockfile (failing on drift) and usually install faster, leading to more deterministic and efficient CI runs.
```suggestion
- name: 进入插件目录并安装依赖
run: |
cd vscode-extension
npm ci
```
</issue_to_address>
### Comment 3
<location path=".github/workflows/build-vscode-extension.yml" line_range="45-52" />
<code_context>
+ cd vscode-extension
+ npm install
+
+ - name: 打包 VSIX
+ id: package
+ run: |
+ cd vscode-extension
+ npx @vscode/vsce package
+ VSIX_FILE=$(ls *.vsix | head -n 1)
+ echo "artifact_name=$VSIX_FILE" >> $GITHUB_OUTPUT
+ echo "vsix_path=vscode-extension/$VSIX_FILE" >> $GITHUB_OUTPUT
</code_context>
<issue_to_address>
**suggestion:** The VSIX file detection relies on `ls` and assumes a single match, which could be fragile
This logic depends on shell globbing and on there being exactly one `.vsix` file, so if multiple packages are present you may upload the wrong artifact. Consider making the filename deterministic by cleaning the directory first, using `vsce package -o <expected-name>.vsix`, or constraining the glob to a more specific pattern (e.g. including version).
```suggestion
- name: 打包 VSIX
id: package
run: |
cd vscode-extension
# 清理旧的 VSIX 文件，避免上传历史构件
rm -f ./*.vsix
# 使用 package.json 中的 name 和 version 生成确定性的文件名
PKG_NAME=$(node -p "require('./package.json').name")
PKG_VERSION=$(node -p "require('./package.json').version")
VSIX_FILE="${PKG_NAME}-${PKG_VERSION}.vsix"
# 以指定的文件名打包 VSIX，避免依赖 ls 和通配符
npx @vscode/vsce package -o "$VSIX_FILE"
echo "artifact_name=$VSIX_FILE" >> $GITHUB_OUTPUT
echo "vsix_path=vscode-extension/$VSIX_FILE" >> $GITHUB_OUTPUT
```
</issue_to_address>
### Comment 4
<location path=".github/workflows/build-vscode-extension.yml" line_range="60-66" />
<code_context>
+ EXPIRY_DATE=$(date -u -d "+5 days" '+%Y-%m-%d %H:%M UTC')
+ echo "expires_at=$EXPIRY_DATE" >> $GITHUB_OUTPUT
+
+ - name: 上传构件
+ uses: actions/upload-artifact@v7
+ with:
+ name: github-chinese-extension
+ path: vscode-extension/*.vsix
+ retention-days: 5
+ archive: false
</code_context>
<issue_to_address>
**suggestion:** Align artifact upload path with the computed VSIX path/output for clarity and consistency
Using `path: vscode-extension/*.vsix` while also computing `vsix_path`/`artifact_name` can upload multiple VSIX files if more than one exists, and may not match the artifact referenced in the PR comment. Please switch the upload path to `${{ steps.package.outputs.vsix_path }}` so the uploaded artifact is guaranteed to be the same one referenced elsewhere.
```suggestion
- name: 上传构件
uses: actions/upload-artifact@v7
with:
name: github-chinese-extension
path: ${{ steps.package.outputs.vsix_path }}
retention-days: 5
archive: false
```
</issue_to_address>
### Comment 5
<location path="vscode-extension/README.md" line_range="75" />
<code_context>
+```shell
+git clone https://github.com/maboloshi/github-chinese.git # 克隆仓库
+
+# 若你的网络环境无法访问 Github 克隆仓库，请自行寻找加速器等解决
+
+cd github-chinese/vscode-extension # 进入插件目录
</code_context>
<issue_to_address>
**issue (typo):** Correct “Github” to the proper capitalization “GitHub”.
Use the official capitalization “GitHub” here for consistency with the rest of the document.
```suggestion
# 若你的网络环境无法访问 GitHub 克隆仓库，请自行寻找加速器等解决
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
📦 GitHub 中文化扩展构建完成
Warning Actions 工作流工件仅保存5天，到期将永久删除 工作流运行详情：https://github.com/th-dd/github-chinese/actions/runs/30896395465 |
* main.user.js Update to 1.9.4.4-2026-07-29 Signed-off-by: action-assistant[bot] <152410706+action-assistant[bot]@users.noreply.github.com> * refactor: 移除根目录 main(vscode).user.js, 统一由扩展维护 (maboloshi#767) * test: fix issue 702 regression expectations (maboloshi#725) --------- Signed-off-by: action-assistant[bot] <152410706+action-assistant[bot]@users.noreply.github.com> Co-authored-by: action-assistant[bot] <152410706+action-assistant[bot]@users.noreply.github.com> Co-authored-by: PtJade Ceramic <185668489+PtJade-Ceramic@users.noreply.github.com> Co-authored-by: saime428 <51110572+saime428@users.noreply.github.com>
将 npm install 改为 npm ci Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com> Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
替换打包方式部分过程 Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com> Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
更换上传文件的匹配方式 Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com> Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
修改错误的拼写 Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com> Signed-off-by: 叹号大帝 <162813557+th-dd@users.noreply.github.com>
Owner
Author
|
@sourcery-ai review |
Owner
Author
|
@sourcery-ai resolve |
There was a problem hiding this comment.
Hey - 我发现了 3 个问题，并留下了一些总体反馈：
- 在构建工作流中，建议在
actions/setup-node里使用 LTS 版本（例如node-version: 'lts/*'或 20），而不是写死为24，以避免该版本过时或不再受支持时导致 CI 失败。 - README 中指向 Actions 工作流的链接（
/actions/workflows/build-vscode-extension）可能缺少.yml后缀；将其更新为完整的工作流 URL，可以确保用户被直接带到正确的工作流运行列表。 - README 指导用户下载
github-chinese-extension.vsix，但工作流上传的是名为github-chinese-extension的构件，其中包含带版本号的 VSIX 文件；将构件名称或 README 中的描述与实际文件名对齐，可以减少用户在下载扩展时的困惑。
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In the build workflow, consider using an LTS version for `actions/setup-node` (e.g. `node-version: 'lts/*'` or 20) instead of hard-coding `24` to avoid CI breakage when that version becomes outdated or unsupported.
- The README link to the Actions workflow (`/actions/workflows/build-vscode-extension`) may be missing the `.yml` suffix; updating it to the exact workflow URL ensures users are taken directly to the correct workflow run list.
- The README instructs users to download `github-chinese-extension.vsix`, but the workflow uploads an artifact named `github-chinese-extension` containing a versioned VSIX file; aligning the artifact name or README wording with the actual file name will reduce confusion for users downloading the extension.
## Individual Comments
### Comment 1
<location path=".github/workflows/build-vscode-extension.yml" line_range="4-6" />
<code_context>
+name: Build Extension
+
+on:
+ # 定时触发：每5天自动运行一次
+ schedule:
+ - cron: '0 0 */5 * *'
+
+ # 代码推送触发：当 vscode-extension 目录有变更时自动构建
</code_context>
<issue_to_address>
**nitpick:** Cron expression `*/5` in the day-of-month field doesn’t give a strict “every 5 days” cadence
The comment states “每5天自动运行一次”, but `0 0 */5 * *` actually means “on days 1, 6, 11, 16, 21, 26, 31 at 00:00”, which introduces gaps at month boundaries (e.g. 31st → 6th). If this cadence is acceptable, update the comment to match the real behavior; if a true rolling 5‑day interval is required, adjust the schedule (e.g. multiple cron entries or a different mechanism).
</issue_to_address>
### Comment 2
<location path="test/issue-702-regression.test.cjs" line_range="259" />
<code_context>
const source = fs.readFileSync(filePath, 'utf8');
const start = source.indexOf(` function ${functionName}(`);
- const end = source.indexOf('\n\n function ', start + 1);
+ const nextFunction = source.slice(start + 1).search(/\r?\n\r?\n function /);
+ const end = nextFunction === -1 ? -1 : start + 1 + nextFunction;
assert.notEqual(start, -1, `${functionName} should exist in ${fileName}`);
</code_context>
<issue_to_address>
**suggestion (testing):** Add a regression test to cover CRLF line endings in `loadRuntimeFunction`.
The regex now intentionally supports both LF and CRLF when locating the next runtime function, but that behavior is only covered indirectly. Please add a focused regression test that passes a synthetic source string with `\r\n\r\n function` separators into `loadRuntimeFunction` (or a small helper) and asserts that `end` is found (i.e., not `-1`). This will explicitly lock in support for mixed newline styles and prevent future regressions.
</issue_to_address>
### Comment 3
<location path="vscode-extension/README.md" line_range="66" />
<code_context>
+
+- [Git](https://git-scm.cn/install) （可选，用于克隆仓库，若不打算安装 Git ，请自行将仓库下载至本地）
+
+- [NodeJS](https://nodejs.org)
+
+#### 构建步骤
</code_context>
<issue_to_address>
**nitpick (typo):** 考虑使用官方写法 “Node.js” 以保持术语一致性
这里写成了 “NodeJS”，建议改为更常见且与官网一致的 “Node.js”，以便与官方文档和社区用法对齐。
```suggestion
- [Node.js](https://nodejs.org)
```
</issue_to_address>帮我变得更有用！请在每条评论上点击 👍 或 👎，我会根据你的反馈改进后续的代码审查。
Original comment in English
Hey - I've found 3 issues, and left some high level feedback:
- In the build workflow, consider using an LTS version for
actions/setup-node(e.g.node-version: 'lts/*'or 20) instead of hard-coding24to avoid CI breakage when that version becomes outdated or unsupported. - The README link to the Actions workflow (
/actions/workflows/build-vscode-extension) may be missing the.ymlsuffix; updating it to the exact workflow URL ensures users are taken directly to the correct workflow run list. - The README instructs users to download
github-chinese-extension.vsix, but the workflow uploads an artifact namedgithub-chinese-extensioncontaining a versioned VSIX file; aligning the artifact name or README wording with the actual file name will reduce confusion for users downloading the extension.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In the build workflow, consider using an LTS version for `actions/setup-node` (e.g. `node-version: 'lts/*'` or 20) instead of hard-coding `24` to avoid CI breakage when that version becomes outdated or unsupported.
- The README link to the Actions workflow (`/actions/workflows/build-vscode-extension`) may be missing the `.yml` suffix; updating it to the exact workflow URL ensures users are taken directly to the correct workflow run list.
- The README instructs users to download `github-chinese-extension.vsix`, but the workflow uploads an artifact named `github-chinese-extension` containing a versioned VSIX file; aligning the artifact name or README wording with the actual file name will reduce confusion for users downloading the extension.
## Individual Comments
### Comment 1
<location path=".github/workflows/build-vscode-extension.yml" line_range="4-6" />
<code_context>
+name: Build Extension
+
+on:
+ # 定时触发：每5天自动运行一次
+ schedule:
+ - cron: '0 0 */5 * *'
+
+ # 代码推送触发：当 vscode-extension 目录有变更时自动构建
</code_context>
<issue_to_address>
**nitpick:** Cron expression `*/5` in the day-of-month field doesn’t give a strict “every 5 days” cadence
The comment states “每5天自动运行一次”, but `0 0 */5 * *` actually means “on days 1, 6, 11, 16, 21, 26, 31 at 00:00”, which introduces gaps at month boundaries (e.g. 31st → 6th). If this cadence is acceptable, update the comment to match the real behavior; if a true rolling 5‑day interval is required, adjust the schedule (e.g. multiple cron entries or a different mechanism).
</issue_to_address>
### Comment 2
<location path="test/issue-702-regression.test.cjs" line_range="259" />
<code_context>
const source = fs.readFileSync(filePath, 'utf8');
const start = source.indexOf(` function ${functionName}(`);
- const end = source.indexOf('\n\n function ', start + 1);
+ const nextFunction = source.slice(start + 1).search(/\r?\n\r?\n function /);
+ const end = nextFunction === -1 ? -1 : start + 1 + nextFunction;
assert.notEqual(start, -1, `${functionName} should exist in ${fileName}`);
</code_context>
<issue_to_address>
**suggestion (testing):** Add a regression test to cover CRLF line endings in `loadRuntimeFunction`.
The regex now intentionally supports both LF and CRLF when locating the next runtime function, but that behavior is only covered indirectly. Please add a focused regression test that passes a synthetic source string with `\r\n\r\n function` separators into `loadRuntimeFunction` (or a small helper) and asserts that `end` is found (i.e., not `-1`). This will explicitly lock in support for mixed newline styles and prevent future regressions.
</issue_to_address>
### Comment 3
<location path="vscode-extension/README.md" line_range="66" />
<code_context>
+
+- [Git](https://git-scm.cn/install) （可选，用于克隆仓库，若不打算安装 Git ，请自行将仓库下载至本地）
+
+- [NodeJS](https://nodejs.org)
+
+#### 构建步骤
</code_context>
<issue_to_address>
**nitpick (typo):** 考虑使用官方写法 “Node.js” 以保持术语一致性
这里写成了 “NodeJS”，建议改为更常见且与官网一致的 “Node.js”，以便与官方文档和社区用法对齐。
```suggestion
- [Node.js](https://nodejs.org)
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
由 Sourcery 提供的摘要
为 VS Code 扩展添加自动化构建工作流，并相应更新扩展文档。
新功能：
增强内容：
CI：
Original summary in English
Summary by Sourcery
自动化构建与分发 VS Code GitHub 中文化 插件，并刷新相关文档、配置和测试。
新功能：
错误修复：
增强改进：
CI：
文档：
测试：
Original summary in English
Summary by Sourcery
Automate building and distribution of the VS Code GitHub 中文化 extension and refresh related documentation, configuration, and tests.
New Features:
Bug Fixes:
Enhancements:
CI:
Documentation:
Tests: