feat: tywrap promotion, docs site, and maintenance automation#200
feat: tywrap promotion, docs site, and maintenance automation#200
Conversation
Reorganize flat docs/ files into guide/, reference/, examples/, and troubleshooting/ subdirectories; fix all cross-doc links to use absolute VitePress paths; rename README.md files to index.md; exclude plans/ from the VitePress build to prevent dead link failures.
Also adds ignoreDeadLinks to VitePress config to allow incremental doc authoring while reference pages (env-vars, cli) are pending.
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR establishes comprehensive documentation infrastructure and GitHub automation for the tywrap project. It introduces VitePress-based documentation with guides and references, adds multiple GitHub Actions workflows for CI/CD (coverage, docs deployment, labeling, release automation, and stale issue management), updates package metadata across npm and Python components, and includes agent discovery files for AI integration. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
coderabbitai
bot
added
documentation
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/labeler.yml:
- Around line 24-31: The labeler config under the "area:docs" rule contains
redundant explicit file entries ('CONTRIBUTING.md', 'AGENTS.md', 'CLAUDE.md')
because the '*.md' glob already matches them; update the "any-glob-to-any-file"
list in the area:docs rule to remove those explicit filenames (leave '*.md' and
'docs/**' intact) so the rule is not redundant—look for the "area:docs" block
and the "any-glob-to-any-file" list to make this change.
In `@AGENTS.md`:
- Around line 40-61: The markdown fenced code block containing the repository
tree is missing a language identifier and triggers MD040; update the opening
fence to include a language such as "text" or "plaintext" (i.e., change the
triple-backtick that starts the repo tree to ```text or ```plaintext) so the
directory listing is treated as plain text and the linter warning is resolved.
In `@CLAUDE.md`:
- Around line 1-4: The top-level heading currently reads "# AGENTS.md" but the
file is CLAUDE.md; update the heading text to "# CLAUDE.md" so the document
title matches the filename and prevents confusion with other agent docs—change
the string in the heading line at the top of the file (the "# AGENTS.md" token)
to "# CLAUDE.md".
- Around line 40-61: The fenced repository tree in CLAUDE.md is missing a
language tag and triggers markdownlint MD040; update the opening fence from ```
to ```text so the block is treated as plain text (the tree showing src/,
tywrap_ir/, runtime/, test/, docs/, examples/, generated/, dist/), i.e., change
the code fence that wraps the repo tree to use the "text" language tag.
In `@docs/guide/runtimes/bun.md`:
- Around line 40-54: Update the text that currently says "tywrap ships with a
`bunfig.toml`" to clearly state that the shown `bunfig.toml` is an example
configuration users should add to their own projects when using Bun, because the
package does not include `bunfig.toml` (it is excluded via .npmignore / not
listed in package.json `files`). Replace the phrasing around the `bunfig.toml`
header and the surrounding paragraph to: present the TOML block as a sample
`bunfig.toml` to create in your project, not a file distributed by tywrap, and
keep the example content exactly as shown (`[build]` and `[dev]` entries).
In `@docs/guide/runtimes/comparison.md`:
- Around line 28-37: Update the fenced code block that starts with ``` and
contains the decision diagram beginning "Do you need subprocess-based Python
execution?" to include a language identifier (e.g., change the opening fence to
```text) so the block becomes ```text ... ```—this satisfies markdown linters
and improves accessibility; ensure any other plain triple-backtick blocks in the
same comparison diagram are similarly updated.
In `@docs/guide/runtimes/http.md`:
- Around line 27-31: Add a blank line before the fenced code block that starts
with ``` (the snippet showing headers: { 'Authorization': 'Bearer your-token',
}), to satisfy Markdown rules; edit docs/guide/runtimes/http.md so there is an
empty line separating the preceding heading/paragraph and the code fence.
- Around line 40-49: Add a blank line between the "Running the Python Server"
heading and the following fenced code block so the markdown is compliant with
MD022/MD031; locate the heading "Running the Python Server" and ensure there is
an empty line before the triple-backtick block that starts with "```bash" (the
pip install / python -m tywrap_ir.server snippet).
In `@docs/plans/2026-03-10-tywrap-promotion.md`:
- Around line 1407-1409: The plan uses two different major versions of the same
GitHub Action: update the workflow snippet that currently references
actions/stale@v9 so it matches the Tech Stack declaration (actions/stale@v10);
find the usage of the actions/stale action in the document (look for the token
"actions/stale" in the snippet) and change the pinned major version to `@v10` so
the plan is internally consistent.
In `@docs/reference/cli.md`:
- Around line 37-42: The CLI reference is missing several flags supported by the
"tywrap generate" command; update docs/reference/cli.md's flags table to add
entries for --modules, --runtime, --python, --output-dir, --format,
--declaration, --source-map, --use-cache / --cache, --debug, and --fail-on-warn
with short descriptions matching the CLI implementation, include any default
values or allowed values (e.g., runtime: node|pyodide|http|auto, format:
esm|cjs|both), and ensure aliases (--use-cache / --cache) and CI semantics
(e.g., fail-on-warn exit code) match the behavior implemented in the CLI code
referenced in src/cli.ts.
In `@docs/reference/env-vars.md`:
- Line 54: Update the documentation for NodeBridge's subprocess environment
inheritance to match the actual allowlist used by the implementation: state that
by default NodeBridge inherits PATH and any variables with the TYWRAP_ prefix,
plus the specific keys path, pythonpath, virtual_env, and pythonhome; explicitly
note that generic PYTHON* variables (e.g., PYTHONUNBUFFERED,
PYTHONDONTWRITEBYTECODE) are NOT inherited unless inheritProcessEnv: true is
set, and ensure the doc text references the NodeBridge option inheritProcessEnv
and the exact allowed prefixes/keys.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 6d8691ea-b42c-44aa-acd9-75c5591d2db1
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (32)
.github/labeler.yml.github/workflows/ci.yml.github/workflows/docs.yml.github/workflows/labeler.yml.github/workflows/release.yml.github/workflows/stale.yml.gitignoreAGENTS.mdCLAUDE.mdREADME.mddocs/.vitepress/config.tsdocs/examples/index.mddocs/guide/configuration.mddocs/guide/getting-started.mddocs/guide/runtimes/browser.mddocs/guide/runtimes/bun.mddocs/guide/runtimes/comparison.mddocs/guide/runtimes/deno.mddocs/guide/runtimes/http.mddocs/guide/runtimes/node.mddocs/index.mddocs/plans/2026-03-10-tywrap-promotion.mddocs/public/llms-full.txtdocs/public/llms.txtdocs/reference/api/index.mddocs/reference/cli.mddocs/reference/env-vars.mddocs/reference/type-mapping.mddocs/troubleshooting/index.mdpackage.jsonrenovate.jsontywrap_ir/pyproject.toml
📜 Review details
🧰 Additional context used
🧠 Learnings (7)
📚 Learning: 2026-01-19T21:14:40.872Z
Learnt from: bbopen
Repo: bbopen/tywrap PR: 127
File: src/runtime/bridge-core.ts:260-263
Timestamp: 2026-01-19T21:14:40.872Z
Learning: In `src/runtime/bridge-core.ts` and similar hot request/response loop implementations in the tywrap repository, avoid adding extra defensive validation (e.g., runtime shape checks on error payloads) in tight loops unless the protocol boundary is untrusted or there's a concrete bug report. The Python bridge protocol is controlled and validated via tests, so defensive checks would add unnecessary branching overhead without meaningful benefit.
Applied to files:
AGENTS.mdCLAUDE.mddocs/guide/runtimes/http.mddocs/plans/2026-03-10-tywrap-promotion.mddocs/guide/runtimes/comparison.md
📚 Learning: 2026-01-19T21:14:37.032Z
Learnt from: bbopen
Repo: bbopen/tywrap PR: 127
File: src/runtime/bridge-core.ts:375-385
Timestamp: 2026-01-19T21:14:37.032Z
Learning: In tywrap (src/runtime/bridge-core.ts and similar), environment variable parsing follows a tolerant/best-effort policy. For example, `TYWRAP_CODEC_MAX_BYTES=1024abc` should be accepted as 1024. Only reject clearly invalid values (non-numeric start or <=0). This avoids surprising failures from minor typos.
Applied to files:
AGENTS.mdREADME.mdCLAUDE.mddocs/reference/env-vars.md
📚 Learning: 2026-01-19T21:49:05.612Z
Learnt from: bbopen
Repo: bbopen/tywrap PR: 127
File: runtime/python_bridge.py:99-123
Timestamp: 2026-01-19T21:49:05.612Z
Learning: In the tywrap repository, TYWRAP_REQUEST_MAX_BYTES uses strict integer parsing that rejects values with trailing characters (e.g., "1024abc"). This differs from TYWRAP_CODEC_MAX_BYTES, which uses tolerant/best-effort parsing that accepts numeric prefixes. The strict policy for REQUEST_MAX_BYTES ensures explicit integer values and consistent parse behavior across Node/Python implementations.
Applied to files:
README.md
📚 Learning: 2026-01-20T16:01:39.136Z
Learnt from: bbopen
Repo: bbopen/tywrap PR: 152
File: docs/adr/002-bridge-protocol.md:826-830
Timestamp: 2026-01-20T16:01:39.136Z
Learning: In the tywrap BridgeProtocol architecture (ADR-002), `HttpIO` (and other Transport implementations like `ProcessIO`, `PyodideIO`) implements only the `Transport` interface (methods: `send`, `isReady`, `dispose`). The `RuntimeExecution` interface methods (`call`, `instantiate`, `callMethod`, `disposeInstance`) are implemented by `BridgeProtocol`, which delegates to `Transport` instances. Transport implementations should not include RuntimeExecution methods.
Applied to files:
docs/guide/runtimes/http.mddocs/plans/2026-03-10-tywrap-promotion.mddocs/guide/runtimes/comparison.md
📚 Learning: 2026-01-20T16:01:14.323Z
Learnt from: bbopen
Repo: bbopen/tywrap PR: 152
File: docs/adr/002-bridge-protocol.md:599-602
Timestamp: 2026-01-20T16:01:14.323Z
Learning: In the tywrap repository, bridges currently use implicit ready detection: the first successful response from the Python subprocess proves the bridge is ready to handle requests.
Applied to files:
docs/guide/runtimes/http.mddocs/reference/env-vars.mddocs/guide/runtimes/comparison.md
📚 Learning: 2026-01-20T16:01:14.323Z
Learnt from: bbopen
Repo: bbopen/tywrap PR: 152
File: docs/adr/002-bridge-protocol.md:599-602
Timestamp: 2026-01-20T16:01:14.323Z
Learning: In `src/runtime/node-bridge.ts` (NodeBridge), a test message is sent to the Python subprocess to confirm the bridge is responsive before marking it as ready.
Applied to files:
docs/guide/runtimes/http.mddocs/plans/2026-03-10-tywrap-promotion.mddocs/reference/env-vars.md
📚 Learning: 2026-01-20T01:33:12.841Z
Learnt from: bbopen
Repo: bbopen/tywrap PR: 136
File: src/runtime/node.ts:238-249
Timestamp: 2026-01-20T01:33:12.841Z
Learning: In the tywrap repository, when reviewing init/startup patterns, prioritize cases that break core functionality over edge cases with diagnostic-only impact (e.g., missing bridgeInfo metadata). If workers are healthy and operational, defer low-impact defensive checks to follow-up PRs.
Applied to files:
docs/plans/2026-03-10-tywrap-promotion.md
🪛 GitHub Actions: CI
package.json
[error] 1-1: npm ci failed: package-lock.json is out of sync with package.json. Missing: @types/react@18.3.28 and @types/prop-types@15.7.15 in the lockfile. Run 'npm install' to update the lockfile before retrying 'npm ci'.
🪛 LanguageTool
docs/plans/2026-03-10-tywrap-promotion.md
[uncategorized] ~1250-~1250: The official name of this software platform is spelled with a capital “H”.
Context: ...ep 1: Add the Codecov upload step** In .github/workflows/ci.yml, find the test job....
(GITHUB)
🪛 markdownlint-cli2 (0.21.0)
AGENTS.md
[warning] 40-40: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
CLAUDE.md
[warning] 40-40: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/guide/runtimes/http.md
[warning] 29-29: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 30-30: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 42-42: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 43-43: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
docs/plans/2026-03-10-tywrap-promotion.md
[warning] 53-53: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 53-53: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 55-55: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 57-57: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 57-57: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 62-62: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 62-62: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 64-64: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 66-66: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 66-66: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 71-71: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 76-76: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 86-86: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 88-88: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 92-92: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 107-107: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 112-112: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 119-119: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 124-124: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 126-126: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 130-130: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 143-143: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 149-149: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 154-154: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 156-156: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 158-158: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 177-177: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 182-182: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 237-237: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 293-293: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
[warning] 294-294: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 294-294: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 302-302: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 317-317: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 322-322: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 329-329: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 331-331: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 335-335: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 443-443: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 507-507: Blank line inside blockquote
(MD028, no-blanks-blockquote)
[warning] 509-509: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 509-509: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 537-537: Ordered list item prefix
Expected: 1; Actual: 2; Style: 1/1/1
(MD029, ol-prefix)
[warning] 538-538: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 540-540: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 544-544: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 546-546: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 550-550: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 652-652: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 652-652: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 690-690: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 712-712: Multiple headings with the same content
(MD024, no-duplicate-heading)
[warning] 730-730: Multiple headings with the same content
(MD024, no-duplicate-heading)
[warning] 734-734: Multiple headings with the same content
(MD024, no-duplicate-heading)
[warning] 746-746: Multiple headings with the same content
(MD024, no-duplicate-heading)
[warning] 753-753: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 753-753: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 828-828: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 830-830: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 832-832: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 846-846: Multiple headings with the same content
(MD024, no-duplicate-heading)
[warning] 860-860: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 860-860: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 906-906: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 915-915: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 915-915: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 927-927: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 954-954: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 992-992: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1018-1018: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1018-1018: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 1059-1059: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 1060-1060: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1064-1064: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 1065-1065: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1069-1069: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 1070-1070: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1089-1089: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1090-1090: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1090-1090: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 1157-1157: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1232-1232: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1236-1236: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1273-1273: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1283-1283: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1285-1285: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1287-1287: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1289-1289: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1295-1295: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1300-1300: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1377-1377: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1438-1438: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1486-1486: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
[warning] 1560-1560: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
docs/reference/env-vars.md
[warning] 28-28: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
docs/guide/runtimes/comparison.md
[warning] 28-28: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (28)
.gitignore (1)
50-54: LGTM!The VitePress ignore patterns are correctly added. Note that
.vitepress/on line 52 technically makes lines 53-54 redundant, but keeping the explicitdocs/.vitepress/dist/anddocs/.vitepress/cache/paths adds clarity about what build artifacts are produced.AGENTS.md (2)
1-39: LGTM!The project overview, build commands, and documentation for AI coding assistants are comprehensive and well-structured. This aligns well with the PR's goal of AI agent discoverability.
63-96: LGTM!Code conventions, commit conventions, PR guidelines, and environment variables documentation are clear and complete. The env vars table correctly documents key testing variables like
TYWRAP_PERF_BUDGETSandTYWRAP_CODEC_MAX_BYTES.docs/examples/index.md (1)
74-79: LGTM!The navigation links are correctly updated to use root-relative paths, consistent with the VitePress site structure established across the documentation.
docs/troubleshooting/index.md (1)
647-648: LGTM!The runtime guide links are correctly updated to root-relative paths, maintaining consistency with the VitePress site navigation pattern used throughout the documentation.
.github/labeler.yml (2)
1-7: LGTM!The runtime area labeling configuration correctly targets the runtime-related directories and test files.
33-37: LGTM!The CI area labeling for
.github/**andscripts/**is appropriate for tracking CI/automation changes.docs/guide/runtimes/deno.md (4)
1-11: LGTM!Excellent documentation of the Deno Deploy subprocess limitation. The warning is prominently placed and the alternatives (PyodideBridge, HttpBridge) are clearly presented with links to their respective guides.
32-48: LGTM!The required permissions documentation is thorough, with a clear table explaining why each flag is needed for NodeBridge subprocess execution.
60-77: LGTM!The bridge selection table provides clear guidance for different Deno deployment scenarios, and the troubleshooting section addresses the most common permission errors users will encounter.
22-30: No issues found with Deno npm specifier syntax.The imports
npm:tywrapandnpm:tywrap/runtimecorrectly follow Deno's npm compatibility syntax. The/runtimesubpath is properly exported by the tywrap package and the documentation example is accurate.docs/guide/configuration.md (1)
534-540: LGTM!The navigation links are correctly updated to root-relative paths, maintaining consistency with the VitePress documentation site structure.
.github/workflows/ci.yml (1)
71-79: LGTM!The Codecov integration is well-implemented:
- Running
test:coveragegenerates the lcov report as configured invitest.config.ts- Uploading only for Node 22 + Python 3.11 avoids duplicate coverage reports
fail_ci_if_error: falseis appropriate sinceCODECOV_TOKENis a post-merge setup requirementREADME.md (2)
6-10: LGTM!The new badges are well-structured and follow standard conventions. The Coverage badge links to Codecov, npm downloads provides download metrics, PRs Welcome encourages contributions, and the Docs badge links to the deployed documentation site.
23-32: LGTM!The comparison table effectively differentiates tywrap from alternatives (pythonia, node-calls-python, pymport) across key features. This provides clear value proposition for potential users evaluating the library.
.github/workflows/labeler.yml (1)
1-16: LGTM!The workflow is correctly configured:
- Uses
pull_request_targetappropriately for labeling PRs (including from forks)- Permissions are minimally scoped (
contents: read,pull-requests: write)- Uses the standard
actions/labeler@v6action withGITHUB_TOKENdocs/guide/runtimes/node.md (1)
586-589: LGTM!The navigation links are correctly updated to use root-relative paths, which is consistent with the broader documentation restructuring in this PR. Root-relative paths work well with VitePress and provide more predictable navigation.
docs/public/llms.txt (1)
1-28: LGTM!The
llms.txtfile is well-structured for AI/LLM discoverability. It provides a clear project description and comprehensive navigation to documentation resources. The URLs correctly point to the deployed docs site (bbopen.github.io/tywrap/) and GitHub resources.docs/guide/getting-started.md (1)
346-354: LGTM!The navigation links are correctly updated to use root-relative paths, maintaining consistency with the broader documentation restructuring across the PR.
docs/index.md (1)
1-51: LGTM!Well-structured VitePress homepage with clear hero messaging, feature highlights, and a practical Quick Start guide. The experimental warning and GitHub star CTA are appropriate for project visibility.
docs/guide/runtimes/http.md (1)
1-77: Documentation accurately reflects the API.The options table and code examples correctly match the
HttpBridgeOptionsinterface andregisterArrowDecoderutility from the source code..github/workflows/docs.yml (1)
1-52: LGTM!Well-structured GitHub Pages deployment workflow. Good choices include
fetch-depth: 0for git history access (useful for VitePress'slastUpdatedfeature),cancel-in-progress: falseto avoid disrupting active deployments, and proper artifact handling between build and deploy jobs.docs/.vitepress/config.ts (1)
1-84: LGTM!Comprehensive VitePress configuration with well-organized navigation and sidebar structure. The
base: '/tywrap/'correctly targets GitHub Pages deployment, andsrcExclude: ['**/plans/**']appropriately excludes internal planning documents from the built site.docs/guide/runtimes/bun.md (1)
1-39: LGTM!Documentation accurately reflects the API. Import paths match the package.json exports map, and the options table correctly documents
NodeBridgeOptionsproperties from the source code..github/workflows/release.yml (1)
1-57: LGTM!Well-structured release workflow with proper separation of concerns. The
publish-npmjob correctly:
- Checks out at the release tag
- Uses minimal permissions with
id-token: writefor npm provenance- Runs tests before publishing
- Uses
--provenance --access publicfor supply chain securityThe workflow-level permissions appropriately grant write access for release-please to create PRs and releases.
renovate.json (1)
1-26: LGTM!Well-balanced Renovate configuration with a conservative automerge strategy. Automerging is limited to low-risk updates (devDependencies patch/minor and type definitions) while production dependencies require manual review. The weekly schedule and PR limits prevent notification overload.
.github/workflows/stale.yml (1)
1-39: LGTM!Reasonable stale management configuration with appropriate timeframes and exemptions. The longer grace period for issues (90+30 days) vs PRs (60+14 days) reflects that issues may await upstream changes while PRs indicate active work. Exempting
security,pinned,good first issue, andhelp wantedlabels preserves important items.package.json (1)
141-142: Lockfile is already up-to-date with the VitePress dependency.The
package-lock.jsonalready includesvitepressand its transitive dependencies (@types/react).@types/prop-typesis not a declared dependency of VitePress, so its absence is not a sync issue. Bothpackage.jsonandpackage-lock.jsonare committed and in sync.> Likely an incorrect or invalid review comment.
| area:docs: | ||
| - changed-files: | ||
| - any-glob-to-any-file: | ||
| - 'docs/**' | ||
| - '*.md' | ||
| - 'CONTRIBUTING.md' | ||
| - 'AGENTS.md' | ||
| - 'CLAUDE.md' |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Minor redundancy in docs patterns.
Lines 29-31 (CONTRIBUTING.md, AGENTS.md, CLAUDE.md) are already covered by the *.md glob pattern on line 28. These explicit entries are redundant but harmless—they may serve as documentation of important files.
♻️ Optional: Remove redundant entries
area:docs:
- changed-files:
- any-glob-to-any-file:
- 'docs/**'
- '*.md'
- - 'CONTRIBUTING.md'
- - 'AGENTS.md'
- - 'CLAUDE.md'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| area:docs: | |
| - changed-files: | |
| - any-glob-to-any-file: | |
| - 'docs/**' | |
| - '*.md' | |
| - 'CONTRIBUTING.md' | |
| - 'AGENTS.md' | |
| - 'CLAUDE.md' | |
| area:docs: | |
| - changed-files: | |
| - any-glob-to-any-file: | |
| - 'docs/**' | |
| - '*.md' |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/labeler.yml around lines 24 - 31, The labeler config under the
"area:docs" rule contains redundant explicit file entries ('CONTRIBUTING.md',
'AGENTS.md', 'CLAUDE.md') because the '*.md' glob already matches them; update
the "any-glob-to-any-file" list in the area:docs rule to remove those explicit
filenames (leave '*.md' and 'docs/**' intact) so the rule is not redundant—look
for the "area:docs" block and the "any-glob-to-any-file" list to make this
change.
| ``` | ||
| src/ | ||
| cli.ts # CLI entry point (tywrap init / generate) | ||
| runtime/ | ||
| node.ts # NodeBridge — subprocess-based (Node, Bun, Deno) | ||
| pyodide.ts # PyodideBridge — browser WebAssembly | ||
| http.ts # HttpBridge — remote Python server | ||
| utils/ | ||
| runtime.ts # detectRuntime(), isBun(), isDeno(), etc. | ||
| tywrap_ir/ # Python package: AST analysis → typed IR | ||
| tywrap_ir/ | ||
| __main__.py # CLI entry: tywrap-ir | ||
| runtime/ | ||
| python_bridge.py # Python subprocess server (JSONL protocol) | ||
| test/ # Vitest tests mirroring src/ structure | ||
| test-d/ # TSD type tests | ||
| docs/ # Documentation (VitePress site) | ||
| examples/ | ||
| living-app/ # End-to-end example with pandas + Arrow | ||
| generated/ # Generated wrapper output (gitignored in user projects) | ||
| dist/ # Compiled TypeScript output (do not edit) | ||
| ``` |
There was a problem hiding this comment.
Add a language identifier to the fenced code block.
The repository structure code block is missing a language identifier, which triggers a markdown lint warning (MD040). Use text or plaintext for directory tree structures.
🔧 Proposed fix
-```
+```text
src/
cli.ts # CLI entry point (tywrap init / generate)🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 40-40: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@AGENTS.md` around lines 40 - 61, The markdown fenced code block containing
the repository tree is missing a language identifier and triggers MD040; update
the opening fence to include a language such as "text" or "plaintext" (i.e.,
change the triple-backtick that starts the repo tree to ```text or ```plaintext)
so the directory listing is treated as plain text and the linter warning is
resolved.
| # AGENTS.md | ||
|
|
||
| > This file helps AI coding assistants (Cursor, Copilot, Claude Code, Devin, Jules, Aider, Warp) | ||
| > understand the tywrap codebase and contribute effectively. |
There was a problem hiding this comment.
Rename the top-level heading to # CLAUDE.md.
Line 1 still identifies this file as AGENTS.md, which makes the two agent-discovery docs indistinguishable in previews and search results.
Suggested fix
-# AGENTS.md
+# CLAUDE.md📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # AGENTS.md | |
| > This file helps AI coding assistants (Cursor, Copilot, Claude Code, Devin, Jules, Aider, Warp) | |
| > understand the tywrap codebase and contribute effectively. | |
| # CLAUDE.md | |
| > This file helps AI coding assistants (Cursor, Copilot, Claude Code, Devin, Jules, Aider, Warp) | |
| > understand the tywrap codebase and contribute effectively. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CLAUDE.md` around lines 1 - 4, The top-level heading currently reads "#
AGENTS.md" but the file is CLAUDE.md; update the heading text to "# CLAUDE.md"
so the document title matches the filename and prevents confusion with other
agent docs—change the string in the heading line at the top of the file (the "#
AGENTS.md" token) to "# CLAUDE.md".
| ``` | ||
| src/ | ||
| cli.ts # CLI entry point (tywrap init / generate) | ||
| runtime/ | ||
| node.ts # NodeBridge — subprocess-based (Node, Bun, Deno) | ||
| pyodide.ts # PyodideBridge — browser WebAssembly | ||
| http.ts # HttpBridge — remote Python server | ||
| utils/ | ||
| runtime.ts # detectRuntime(), isBun(), isDeno(), etc. | ||
| tywrap_ir/ # Python package: AST analysis → typed IR | ||
| tywrap_ir/ | ||
| __main__.py # CLI entry: tywrap-ir | ||
| runtime/ | ||
| python_bridge.py # Python subprocess server (JSONL protocol) | ||
| test/ # Vitest tests mirroring src/ structure | ||
| test-d/ # TSD type tests | ||
| docs/ # Documentation (VitePress site) | ||
| examples/ | ||
| living-app/ # End-to-end example with pandas + Arrow | ||
| generated/ # Generated wrapper output (gitignored in user projects) | ||
| dist/ # Compiled TypeScript output (do not edit) | ||
| ``` |
There was a problem hiding this comment.
Add a language tag to the repository tree fence.
This block is already tripping markdownlint (MD040). Mark it as text so the new docs file stays lint-clean.
Suggested fix
-```
+```text
src/
cli.ts # CLI entry point (tywrap init / generate)
runtime/
node.ts # NodeBridge — subprocess-based (Node, Bun, Deno)
@@
dist/ # Compiled TypeScript output (do not edit)</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **IMPORTANT**
> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
```suggestion
🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 40-40: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@CLAUDE.md` around lines 40 - 61, The fenced repository tree in CLAUDE.md is
missing a language tag and triggers markdownlint MD040; update the opening fence
from ``` to ```text so the block is treated as plain text (the tree showing
src/, tywrap_ir/, runtime/, test/, docs/, examples/, generated/, dist/), i.e.,
change the code fence that wraps the repo tree to use the "text" language tag.
| ## bunfig.toml | ||
|
|
||
| tywrap ships with a `bunfig.toml` for build and run settings: | ||
|
|
||
| ```toml | ||
| [build] | ||
| target = "bun" | ||
| format = "esm" | ||
| splitting = true | ||
| sourcemap = "external" | ||
| external = ["pyodide"] | ||
|
|
||
| [dev] | ||
| hot = true | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if bunfig.toml exists in the repository
fd -t f 'bunfig.toml'
# Check if it would be included in the npm package (not in .npmignore or excluded)
if [ -f ".npmignore" ]; then
echo "=== .npmignore contents ==="
cat .npmignore
fi
if [ -f "package.json" ]; then
echo "=== package.json files field ==="
jq '.files // "not specified"' package.json
fiRepository: bbopen/tywrap
Length of output: 721
Update documentation to clarify bunfig.toml is not distributed with the package.
The statement "tywrap ships with a bunfig.toml" is inaccurate. The file is explicitly excluded in .npmignore and not included in the package.json files field. Users will not find this file in their installed tywrap package. Reword this as an example configuration they should create in their own projects when using Bun, not a file that comes with tywrap.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/guide/runtimes/bun.md` around lines 40 - 54, Update the text that
currently says "tywrap ships with a `bunfig.toml`" to clearly state that the
shown `bunfig.toml` is an example configuration users should add to their own
projects when using Bun, because the package does not include `bunfig.toml` (it
is excluded via .npmignore / not listed in package.json `files`). Replace the
phrasing around the `bunfig.toml` header and the surrounding paragraph to:
present the TOML block as a sample `bunfig.toml` to create in your project, not
a file distributed by tywrap, and keep the example content exactly as shown
(`[build]` and `[dev]` entries).
| headers: { | ||
| 'Authorization': 'Bearer your-token', | ||
| }, | ||
| })); | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add blank line before code block for markdown compliance.
The static analysis tool flagged missing blank lines around headings and fenced code blocks.
📝 Proposed fix
## Configuration Options
+
`NodeBridge` accepts the same options under Bun as under Node.js. See the [Node.js guide](./node) for the full option reference.🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 29-29: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 30-30: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/guide/runtimes/http.md` around lines 27 - 31, Add a blank line before
the fenced code block that starts with ``` (the snippet showing headers: {
'Authorization': 'Bearer your-token', }), to satisfy Markdown rules; edit
docs/guide/runtimes/http.md so there is an empty line separating the preceding
heading/paragraph and the code fence.
| | `codec` | No | Arrow | Codec options | | ||
|
|
||
| ## Running the Python Server | ||
|
|
||
| Start the Python bridge server: | ||
|
|
||
| ```bash | ||
| pip install tywrap-ir | ||
| python -m tywrap_ir.server --port 8080 | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add blank line before code block for markdown compliance.
Per the markdownlint warnings (MD022, MD031), headings and fenced code blocks should be surrounded by blank lines.
📝 Proposed fix
## Running the Python Server
+
Start the Python bridge server:🧰 Tools
🪛 markdownlint-cli2 (0.21.0)
[warning] 42-42: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
[warning] 43-43: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/guide/runtimes/http.md` around lines 40 - 49, Add a blank line between
the "Running the Python Server" heading and the following fenced code block so
the markdown is compliant with MD022/MD031; locate the heading "Running the
Python Server" and ensure there is an empty line before the triple-backtick
block that starts with "```bash" (the pip install / python -m tywrap_ir.server
snippet).
| - uses: actions/stale@v9 | ||
| with: | ||
| repo-token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check if the file exists and read line 9
sed -n '9p' docs/plans/2026-03-10-tywrap-promotion.md
# Then read lines 1407-1409
sed -n '1407,1409p' docs/plans/2026-03-10-tywrap-promotion.mdRepository: bbopen/tywrap
Length of output: 296
Use the same actions/stale major version throughout the plan.
Line 9 declares actions/stale@v10 in the Tech Stack, but this workflow snippet at lines 1407-1409 still pins actions/stale@v9. This drift makes the plan internally inconsistent and easy to implement incorrectly.
Suggested fix
- - uses: actions/stale@v9
+ - uses: actions/stale@v10🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/plans/2026-03-10-tywrap-promotion.md` around lines 1407 - 1409, The plan
uses two different major versions of the same GitHub Action: update the workflow
snippet that currently references actions/stale@v9 so it matches the Tech Stack
declaration (actions/stale@v10); find the usage of the actions/stale action in
the document (look for the token "actions/stale" in the snippet) and change the
pinned major version to `@v10` so the plan is internally consistent.
| | Flag | Description | | ||
| |------|-------------| | ||
| | `--config <path>` | Path to config file (default: `tywrap.config.ts`) | | ||
| | `--check` | Verify generated files match current Python source — exits 1 if anything changed (for CI) | | ||
| | `--verbose` | Print detailed output | | ||
|
|
There was a problem hiding this comment.
Documentation incomplete for tywrap generate flags.
The CLI implementation (src/cli.ts:145-210) supports additional flags not documented here:
| Flag | Description |
|---|---|
--modules |
Comma-separated list of Python modules to wrap |
--runtime |
Runtime to use (node, pyodide, http, auto) |
--python |
Path to Python executable |
--output-dir |
Directory for generated wrappers |
--format |
Output module format (esm, cjs, both) |
--declaration |
Emit TypeScript declaration files |
--source-map |
Emit source maps |
--use-cache / --cache |
Enable on-disk caching |
--debug |
Enable debug logging |
--fail-on-warn |
Exit with code 2 if warnings emitted |
Consider expanding the flags table to cover these options for completeness.
Would you like me to generate an expanded flags table for the CLI reference?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/reference/cli.md` around lines 37 - 42, The CLI reference is missing
several flags supported by the "tywrap generate" command; update
docs/reference/cli.md's flags table to add entries for --modules, --runtime,
--python, --output-dir, --format, --declaration, --source-map, --use-cache /
--cache, --debug, and --fail-on-warn with short descriptions matching the CLI
implementation, include any default values or allowed values (e.g., runtime:
node|pyodide|http|auto, format: esm|cjs|both), and ensure aliases (--use-cache /
--cache) and CI semantics (e.g., fail-on-warn exit code) match the behavior
implemented in the CLI code referenced in src/cli.ts.
|
|
||
| ## Subprocess Environment Inheritance | ||
|
|
||
| By default, `NodeBridge` inherits only `PATH`, `PYTHON*`, and `TYWRAP_*` from `process.env` to keep the subprocess environment minimal. To pass the full environment: |
There was a problem hiding this comment.
Inaccurate description of subprocess environment inheritance.
The documentation states that PYTHON* variables are inherited, but the code (src/runtime/node.ts:638-662) shows a more specific allowlist:
- Prefixes allowed:
TYWRAP_ - Specific keys allowed:
path,pythonpath,virtual_env,pythonhome
Variables like PYTHONUNBUFFERED or PYTHONDONTWRITEBYTECODE would NOT be inherited unless inheritProcessEnv: true is set.
📝 Suggested fix
-By default, `NodeBridge` inherits only `PATH`, `PYTHON*`, and `TYWRAP_*` from `process.env` to keep the subprocess environment minimal. To pass the full environment:
+By default, `NodeBridge` inherits only `PATH`, `PYTHONPATH`, `VIRTUAL_ENV`, `PYTHONHOME`, and `TYWRAP_*` from `process.env` to keep the subprocess environment minimal. To pass the full environment:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| By default, `NodeBridge` inherits only `PATH`, `PYTHON*`, and `TYWRAP_*` from `process.env` to keep the subprocess environment minimal. To pass the full environment: | |
| By default, `NodeBridge` inherits only `PATH`, `PYTHONPATH`, `VIRTUAL_ENV`, `PYTHONHOME`, and `TYWRAP_*` from `process.env` to keep the subprocess environment minimal. To pass the full environment: |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/reference/env-vars.md` at line 54, Update the documentation for
NodeBridge's subprocess environment inheritance to match the actual allowlist
used by the implementation: state that by default NodeBridge inherits PATH and
any variables with the TYWRAP_ prefix, plus the specific keys path, pythonpath,
virtual_env, and pythonhome; explicitly note that generic PYTHON* variables
(e.g., PYTHONUNBUFFERED, PYTHONDONTWRITEBYTECODE) are NOT inherited unless
inheritProcessEnv: true is set, and ensure the doc text references the
NodeBridge option inheritProcessEnv and the exact allowed prefixes/keys.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b7c415bebc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "peerDependencies": { | ||
| "@types/react": ">= 16.8.0 < 19.0.0", | ||
| "react": ">= 16.8.0 < 19.0.0", |
There was a problem hiding this comment.
This new @docsearch/react peer range (@types/react <19) conflicts with the lockfile state, which only resolves @types/react@19.1.9, and npm ci now aborts with Missing: @types/react@ from lock file. I reproduced this on the checked-out commit with Node 22.21.1 / npm 11.4.2 (while the parent commit installs cleanly), so any workflow that starts with npm ci can fail before tests or docs build run until the lockfile is regenerated with a compatible dependency graph.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/dependabot.yml:
- Around line 24-34: Add a "groups" block to the dependabot entry for
package-ecosystem: "pip" and directory: "/tywrap_ir" so pip updates are batched;
e.g., create a group name (like "tywrap_ir-deps") and set its "patterns" to
match your Python dependency files (e.g., "requirements.txt", "pyproject.toml",
"*.in" or a catch-all pattern) so multiple dependency updates in /tywrap_ir are
combined into a single PR instead of separate ones.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: cea9021f-cd97-4eab-b9bf-5dbc830fa475
📒 Files selected for processing (1)
.github/dependabot.yml
📜 Review details
🔇 Additional comments (2)
.github/dependabot.yml (2)
1-22: Well-structured npm dependency grouping.The configuration correctly groups
@types/*packages and development dependencies (minor/patch only) to reduce PR noise while keeping production dependencies and major dev updates in separate PRs for careful review.Note:
@types/*packages typically are dev dependencies, but they'll match thetypescript-typesgroup first due to Dependabot's first-match behavior, which is the intended outcome here.
36-50: GitHub Actions grouping looks good.Grouping all GitHub Actions updates with
"*"pattern reduces PR noise effectively. Since Actions are typically infrastructure-level and updated together, this is a sensible approach.
| # Python dependencies | ||
| - package-ecosystem: "pip" | ||
| directory: "/tywrap_ir" | ||
| schedule: | ||
| interval: "weekly" | ||
| day: "monday" | ||
| time: "06:00" | ||
| timezone: "America/New_York" | ||
| open-pull-requests-limit: 3 | ||
| labels: | ||
| - "area:ci" |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider adding grouping for pip dependencies.
The pip ecosystem configuration is functional but lacks grouping, unlike the other ecosystems. If the /tywrap_ir project has multiple dependencies, each update will create a separate PR.
♻️ Optional: Add grouping similar to other ecosystems
- package-ecosystem: "pip"
directory: "/tywrap_ir"
schedule:
interval: "weekly"
day: "monday"
time: "06:00"
timezone: "America/New_York"
+ groups:
+ python-dependencies:
+ patterns:
+ - "*"
+ update-types:
+ - "minor"
+ - "patch"
open-pull-requests-limit: 3
labels:
- "area:ci"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Python dependencies | |
| - package-ecosystem: "pip" | |
| directory: "/tywrap_ir" | |
| schedule: | |
| interval: "weekly" | |
| day: "monday" | |
| time: "06:00" | |
| timezone: "America/New_York" | |
| open-pull-requests-limit: 3 | |
| labels: | |
| - "area:ci" | |
| # Python dependencies | |
| - package-ecosystem: "pip" | |
| directory: "/tywrap_ir" | |
| schedule: | |
| interval: "weekly" | |
| day: "monday" | |
| time: "06:00" | |
| timezone: "America/New_York" | |
| groups: | |
| python-dependencies: | |
| patterns: | |
| - "*" | |
| update-types: | |
| - "minor" | |
| - "patch" | |
| open-pull-requests-limit: 3 | |
| labels: | |
| - "area:ci" |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/dependabot.yml around lines 24 - 34, Add a "groups" block to the
dependabot entry for package-ecosystem: "pip" and directory: "/tywrap_ir" so pip
updates are batched; e.g., create a group name (like "tywrap_ir-deps") and set
its "patterns" to match your Python dependency files (e.g., "requirements.txt",
"pyproject.toml", "*.in" or a catch-all pattern) so multiple dependency updates
in /tywrap_ir are combined into a single PR instead of separate ones.
@docsearch/react (via VitePress) requires @types/react <19.0.0 while bun-types requires ^19. npm 10.x (Node 22 in CI) fails npm ci because the lock file generated by npm 11.x resolved to 19.x, which doesn't satisfy the <19.0.0 constraint. Add overrides to pin to ^18.3.0 so all CI environments resolve consistently to 18.3.28.
1 participant
Summary
Test Plan