Add documentation landing page for Cloudflare Workers deployment#8
Conversation
- Create static documentation site in docs/ directory - Add index.html with modern, responsive design - Include Getting Started, Features, and Migration guide sections - Add wrangler.toml for Cloudflare Workers static assets deployment - Add .npmignore to ensure docs/ is excluded from npm package - Add docs/README.md with deployment instructions The documentation site showcases: - Project overview and features - Step-by-step getting started guide - v1.0.0 breaking changes and migration guide - Differences from the original @modelcontextprotocol/create-server The site can be deployed to Cloudflare Workers as static assets and is excluded from npm package distribution.
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughIntroduces a comprehensive Astro-based documentation site for create-mcp-tools with multilingual support (English/Japanese), Cloudflare Workers deployment, GitHub Actions CI/CD workflow, and modifies src/index.ts to support CI environments with appropriate default configurations. Changes
Sequence DiagramsequenceDiagram
participant GH as GitHub
participant GHA as GitHub Actions
participant Node as Node.js
participant CF as Cloudflare<br/>Workers
participant Repo as Repository
GH->>GHA: Push to main / Release published
activate GHA
GHA->>Node: Setup Node 20
GHA->>Node: npm ci (docs/)
GHA->>Repo: Fetch GitHub releases & README
Node->>Repo: fetch-github-data.js
Repo-->>Node: releases + readme
Node->>Node: npm run build (Astro)
Node-->>GHA: dist/ (static site)
GHA->>CF: npx wrangler deploy
CF-->>GHA: Deployment complete
deactivate GHA
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
Summary of ChangesHello @hideokamoto, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! このプルリクエストは、 Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds a well-structured documentation site for the create-mcp-tools project, including deployment instructions for Cloudflare Workers. The design is modern and responsive. I've provided some feedback to improve accessibility, maintainability, and clarity. The most critical point is regarding the navigation on mobile devices, which is currently hidden. Please also review the GitHub repository links, as they seem to point to a different project.
.npmignore
Outdated
| src/ | ||
| tsconfig.json |
There was a problem hiding this comment.
While not incorrect, ignoring src/ and tsconfig.json here is redundant because the files field in package.json is already configured to only include the build and template directories. For consistency and to have a single source of truth for what's included in the package, you might consider relying solely on the files field.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
docs/wrangler.toml (1)
10-10: Add a comment warning about the placeholder zone_name.The
zone_name = "your-domain.com"placeholder requires manual configuration before deployment. While docs/README.md documents this requirement, adding a clear inline comment in the config itself would help prevent deployment errors.# Routes routes = [ - { pattern = "/*", zone_name = "your-domain.com" } + { pattern = "/*", zone_name = "your-domain.com" } # TODO: Replace with your actual domain ]docs/index.html (2)
1-7: Consider the audience and language strategy.The entire page is in Japanese, including all UI text, section headings, code examples, and instructions. While this may be intentional, it's unusual for a technical landing page without an explicit language selection or English fallback. Consider documenting the language choice or providing an English version for international accessibility.
317-334: Mobile navigation is hidden without alternative.The media query at max-width: 768px hides
.nav-linksentirely on mobile devices but provides no alternative mobile menu. This makes navigation inaccessible on smaller screens.Consider adding a mobile hamburger menu:
.nav-links { display: flex; gap: 30px; list-style: none; } + .mobile-menu-btn { + display: none; + background: none; + border: none; + font-size: 24px; + cursor: pointer; + } @media (max-width: 768px) { .hero h1 { font-size: 36px; } .nav-links { display: none; } + .mobile-menu-btn { + display: block; + } }Then add the button to the header and wire it with a simple click handler to toggle visibility.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.npmignore(1 hunks)docs/README.md(1 hunks)docs/index.html(1 hunks)docs/wrangler.toml(1 hunks)
🔇 Additional comments (4)
.npmignore (1)
1-16: Well-organized exclusion patterns.The .npmignore file correctly excludes the new docs/ directory along with source files and development artifacts from npm distribution, aligning with the PR objective.
docs/README.md (1)
1-46: Clear deployment instructions.The documentation provides comprehensive steps for deploying to Cloudflare Workers, including the important reminder to customize zone_name in wrangler.toml before deployment. Instructions are well-structured with local preview guidance.
docs/index.html (2)
8-335: Styling is well-structured and responsive.The inline CSS uses clear design tokens (CSS variables), maintains good visual hierarchy, and includes responsive breakpoints. The feature cards, code blocks, and comparison sections are well-styled.
362-413: Content sections are comprehensive and well-organized.The Getting Started, Features, and Breaking Changes sections provide clear information with appropriate code examples and visual formatting. The comparison between old and new APIs is particularly effective for migration guidance.
Also applies to: 415-460, 462-529
Major Changes: - Replaced static HTML with Astro-based documentation site - Added multi-language support (English and Japanese) - Automated GitHub data fetching (releases and README) - Integrated with GitHub Actions for automatic deployment Features: - Dynamic content from GitHub API (releases, README) - Bilingual support: / (English) and /ja (Japanese) - Modern, responsive design with gradient hero section - Automated build and deployment workflow Technical Details: - Built with Astro 5.15.8 for static site generation - Fetches GitHub releases and README at build time - Cloudflare Pages deployment via GitHub Actions - Separated docs build from npm package (excluded via .npmignore) Files Added: - docs/src/pages/index.astro (English) - docs/src/pages/ja/index.astro (Japanese) - docs/scripts/fetch-github-data.js (GitHub data fetcher) - docs/astro.config.mjs (Astro configuration) - .github/workflows/deploy-docs.yml (CI/CD workflow) - docs/DEPLOYMENT.md (Deployment guide) Files Modified: - docs/README.md (Updated with Astro instructions) - docs/wrangler.toml (Simplified for Cloudflare Pages) Files Removed: - docs/index.html (Replaced by Astro pages) Deployment: The site automatically deploys to Cloudflare Pages on: - Push to main branch - New release publication - Manual workflow trigger
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (5)
docs/src/layouts/Layout.astro (1)
18-412: Consider extracting styles for better maintainability.The 394-line inline CSS block encompasses all styling for the documentation site. While functional for a small site, this approach has maintainability drawbacks:
- Difficult to navigate and locate specific styles
- No style encapsulation between components
- Harder to reuse or share styles across different layouts
Consider refactoring by:
- Moving global styles to a separate CSS file imported in the layout
- Using Astro's scoped styles in individual components
- Extracting reusable utility classes into a design system
Example structure:
docs/src/styles/ ├── global.css # Reset, variables, typography ├── components.css # Shared component styles └── utilities.css # Utility classesThis refactor can be deferred if the docs site remains small and simple.
docs/package.json (1)
14-16: Remove the unused @astrojs/node dependency.The
@astrojs/nodeadapter is unnecessary for a static site configuration. Theastro.config.mjsusesoutput: 'static'and does not import the Node adapter. The Node adapter is only required foroutput: 'server'oroutput: 'hybrid'modes. Remove this dependency fromdocs/package.jsonto reduce bundle size and clarify project intent..github/workflows/deploy-docs.yml (3)
19-27: Consider pinning action versions to specific commits or tags.Using major version tags (
@v4) provides automatic updates but can introduce unexpected changes. For better reproducibility and security, consider pinning to specific versions or commit SHAs.Apply this diff to pin to specific versions:
- name: Checkout - uses: actions/checkout@v4 + uses: actions/checkout@v4.2.2 - name: Setup Node.js - uses: actions/setup-node@v4 + uses: actions/setup-node@v4.1.0Alternatively, use commit SHAs for maximum security and reproducibility.
29-41: Consider using working-directory for cleaner workflow.The workflow repeatedly uses
cd docsin run commands. Setting a defaultworking-directorywould be cleaner and less error-prone.Apply this diff to simplify the workflow:
- name: Install dependencies + working-directory: docs run: | - cd docs npm ci - name: Build site + working-directory: docs run: | - cd docs npm run build env: # GitHub APIのレート制限を回避するため、GITHUB_TOKENを使用 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
43-43: Pin Cloudflare Pages action to a specific version.Using
@v1for the Cloudflare Pages action can introduce unexpected breaking changes. Pin to a specific version for stability.Apply this diff:
- name: Deploy to Cloudflare Pages - uses: cloudflare/pages-action@v1 + uses: cloudflare/pages-action@v1.5.0Check the latest stable version before applying.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
docs/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (13)
.github/workflows/deploy-docs.yml(1 hunks)docs/.gitignore(1 hunks)docs/DEPLOYMENT.md(1 hunks)docs/README.md(1 hunks)docs/astro.config.mjs(1 hunks)docs/package.json(1 hunks)docs/scripts/fetch-github-data.js(1 hunks)docs/src/components/Header.astro(1 hunks)docs/src/data/github.json(1 hunks)docs/src/layouts/Layout.astro(1 hunks)docs/src/pages/index.astro(1 hunks)docs/src/pages/ja/index.astro(1 hunks)docs/wrangler.toml(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- docs/DEPLOYMENT.md
🚧 Files skipped from review as they are similar to previous changes (2)
- docs/README.md
- docs/wrangler.toml
🔇 Additional comments (14)
docs/.gitignore (1)
1-3: LGTM!The ignore patterns are appropriate for an Astro project, covering dependencies, build output, and Astro's cache directory.
docs/src/data/github.json (1)
1-5: LGTM!This is a generated data file that will be populated by the
fetch-github-data.jsscript during the build process. The empty releases array is expected initial state.docs/src/pages/index.astro (2)
1-13: LGTM!The frontmatter setup correctly imports dependencies and initializes data. The
latestReleaseaccess is safe because it's conditionally rendered on line 24.
192-203: Verify sanitization of GitHub release body content.The release body is rendered using
set:htmlwith minimal processing (newline to<br>conversion). While GitHub API data is generally trustworthy, if a release contains malicious HTML/JavaScript in the body field, it could pose an XSS risk.Consider sanitizing the HTML or using Markdown rendering:
- <div class="release-body" set:html={release.body?.replace(/\n/g, '<br>')} /> + <div class="release-body">{release.body?.replace(/\n/g, '\n')}</div>Or install a Markdown renderer if release bodies use Markdown formatting.
docs/src/components/Header.astro (1)
1-26: LGTM!The header component is well-structured with proper TypeScript typing for the lang prop. Language switching logic is clean and the conditional rendering for bilingual labels is implemented correctly.
docs/scripts/fetch-github-data.js (2)
40-50: LGTM!The README fetch function correctly reads from the repository root using the relative path
../../README.md. Error handling appropriately returns an empty string on failure.
52-74: LGTM!The main function efficiently fetches data in parallel using
Promise.alland properly writes the formatted JSON output. Error handling and logging are appropriate.docs/src/layouts/Layout.astro (1)
1-9: LGTM!The Props interface is properly typed with TypeScript, and the default value for
langensures the component works correctly when no language is specified.docs/src/pages/ja/index.astro (3)
22-83: LGTM!The hero section properly uses conditional rendering for the release badge, and the getting started guide provides clear, well-structured examples with appropriate HTML entity escaping for code blocks.
85-199: LGTM!The features grid and migration guide are well-structured with clear API comparisons. HTML entity escaping is correctly applied to prevent parsing issues in code examples.
225-272: LGTM!The differences section and footer are well-structured with appropriate links and license information.
.github/workflows/deploy-docs.yml (3)
1-17: LGTM!The workflow triggers are appropriate for documentation deployment, and permissions follow the principle of least privilege with minimal required access.
48-48: Configuration is correctly aligned.The Astro configuration (
outDir: './dist'in docs/astro.config.mjs) outputs todocs/dist, which matches the directory specified in the workflow (directory: docs/dist). No changes needed.
45-47: Secrets and project name are properly documented—no action required.The deployment guide at
docs/DEPLOYMENT.mdcomprehensively documents bothCLOUDFLARE_API_TOKENandCLOUDFLARE_ACCOUNT_ID, including step-by-step setup instructions and where to obtain the Account ID from the Cloudflare dashboard. The project namecreate-mcp-tools-docsis explicitly specified in the initial setup steps and confirmed in the manual deployment instructions, matching the workflow configuration.
| async function fetchReleases() { | ||
| try { | ||
| const url = `https://api.github.com/repos/${REPO_OWNER}/${REPO_NAME}/releases`; | ||
| const response = await fetch(url, { | ||
| headers: { | ||
| 'Accept': 'application/vnd.github.v3+json', | ||
| 'User-Agent': 'create-mcp-tools-docs' | ||
| } | ||
| }); | ||
|
|
||
| if (!response.ok) { | ||
| console.warn('Failed to fetch releases from GitHub API, using empty array'); | ||
| return []; | ||
| } | ||
|
|
||
| const releases = await response.json(); | ||
| return releases.map(release => ({ | ||
| name: release.name, | ||
| tag_name: release.tag_name, | ||
| published_at: release.published_at, | ||
| body: release.body, | ||
| html_url: release.html_url, | ||
| prerelease: release.prerelease, | ||
| draft: release.draft | ||
| })); | ||
| } catch (error) { | ||
| console.error('Error fetching releases:', error.message); | ||
| return []; | ||
| } | ||
| } |
There was a problem hiding this comment.
Add GitHub token authentication to avoid rate limiting.
The GitHub API requests are unauthenticated, which limits requests to 60 per hour per IP. During CI/CD builds or frequent local development, this could easily hit rate limits and cause build failures.
Apply this diff to add authentication support:
async function fetchReleases() {
try {
const url = `https://api.github.com/repos/${REPO_OWNER}/${REPO_NAME}/releases`;
+ const headers = {
+ 'Accept': 'application/vnd.github.v3+json',
+ 'User-Agent': 'create-mcp-tools-docs'
+ };
+
+ // Add authentication if token is available
+ if (process.env.GITHUB_TOKEN) {
+ headers['Authorization'] = `Bearer ${process.env.GITHUB_TOKEN}`;
+ }
+
const response = await fetch(url, {
- headers: {
- 'Accept': 'application/vnd.github.v3+json',
- 'User-Agent': 'create-mcp-tools-docs'
- }
+ headers
});Then document the optional GITHUB_TOKEN environment variable in the deployment documentation.
📝 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.
| async function fetchReleases() { | |
| try { | |
| const url = `https://api.github.com/repos/${REPO_OWNER}/${REPO_NAME}/releases`; | |
| const response = await fetch(url, { | |
| headers: { | |
| 'Accept': 'application/vnd.github.v3+json', | |
| 'User-Agent': 'create-mcp-tools-docs' | |
| } | |
| }); | |
| if (!response.ok) { | |
| console.warn('Failed to fetch releases from GitHub API, using empty array'); | |
| return []; | |
| } | |
| const releases = await response.json(); | |
| return releases.map(release => ({ | |
| name: release.name, | |
| tag_name: release.tag_name, | |
| published_at: release.published_at, | |
| body: release.body, | |
| html_url: release.html_url, | |
| prerelease: release.prerelease, | |
| draft: release.draft | |
| })); | |
| } catch (error) { | |
| console.error('Error fetching releases:', error.message); | |
| return []; | |
| } | |
| } | |
| async function fetchReleases() { | |
| try { | |
| const url = `https://api.github.com/repos/${REPO_OWNER}/${REPO_NAME}/releases`; | |
| const headers = { | |
| 'Accept': 'application/vnd.github.v3+json', | |
| 'User-Agent': 'create-mcp-tools-docs' | |
| }; | |
| // Add authentication if token is available | |
| if (process.env.GITHUB_TOKEN) { | |
| headers['Authorization'] = `Bearer ${process.env.GITHUB_TOKEN}`; | |
| } | |
| const response = await fetch(url, { | |
| headers | |
| }); | |
| if (!response.ok) { | |
| console.warn('Failed to fetch releases from GitHub API, using empty array'); | |
| return []; | |
| } | |
| const releases = await response.json(); | |
| return releases.map(release => ({ | |
| name: release.name, | |
| tag_name: release.tag_name, | |
| published_at: release.published_at, | |
| body: release.body, | |
| html_url: release.html_url, | |
| prerelease: release.prerelease, | |
| draft: release.draft | |
| })); | |
| } catch (error) { | |
| console.error('Error fetching releases:', error.message); | |
| return []; | |
| } | |
| } |
🤖 Prompt for AI Agents
In docs/scripts/fetch-github-data.js around lines 9 to 38, the GitHub API
requests are unauthenticated and may hit the 60/hr rate limit; update the fetch
call to read process.env.GITHUB_TOKEN and, if present, add an Authorization
header (e.g., "Authorization: token <GITHUB_TOKEN>" or "Bearer <GITHUB_TOKEN>")
to the request headers, preserving existing Accept and User-Agent headers, and
ensure the try/catch and response handling remain unchanged; after code changes,
add a short note to the deployment docs documenting the optional GITHUB_TOKEN
environment variable and its purpose.
Changed deployment method from Cloudflare Pages to Cloudflare Workers Static Assets for better performance and simpler configuration. Changes: - Updated GitHub Actions workflow to use wrangler deploy instead of Pages Action - Modified wrangler.toml to configure Static Assets with binding - Added src/index.js as the Worker entry point for serving static files - Updated DEPLOYMENT.md with Workers-specific deployment instructions - Updated README.md to reflect new deployment method Benefits of Workers Static Assets: - Simpler deployment process (single wrangler deploy command) - Direct control over the Worker script - Better integration with Cloudflare's edge network - No separate Pages project needed Configuration: - Static assets served from dist/ directory via ASSETS binding - Worker script in src/index.js handles requests - Automatic deployment on push to main or release publication
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
.github/workflows/deploy-docs.yml (1)
41-47: Deployment step looks good.The Wrangler deployment command correctly uses Cloudflare secrets for authentication.
Consider pinning the Wrangler version for more reproducible deployments:
- name: Deploy to Cloudflare Workers run: | cd docs - npx wrangler deploy + npx wrangler@3 deployThis ensures consistent behavior across deployments, though using the latest version via
npxis also a valid approach.docs/src/index.js (1)
1-7: Clean minimal implementation for static asset serving.This follows the standard Cloudflare Workers Static Assets pattern where the ASSETS binding handles static file serving, caching, and error responses automatically. For a documentation site, this simplicity is perfectly appropriate.
If you want defensive coding against potential binding issues, you could optionally add error handling:
export default { async fetch(request, env) { - // Serve static assets from the ASSETS binding - return env.ASSETS.fetch(request); + // Serve static assets from the ASSETS binding + try { + return await env.ASSETS.fetch(request); + } catch (error) { + return new Response('Service temporarily unavailable', { status: 503 }); + } }, };However, this is purely defensive—the ASSETS binding is reliable and handles errors internally.
docs/DEPLOYMENT.md (1)
59-59: Add language identifier to code block.The markdown linter correctly flagged this code block for missing a language specification.
Apply this diff to fix the linter warning:
-``` +```bash npx wrangler deployBased on static analysis hints. </blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: CodeRabbit UI **Review profile**: CHILL **Plan**: Pro <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between ef51397c913454eb7e478c3ec063e82beec69f33 and b24f5a49f9a143d0bf50d6a7d7db989ef38ddf36. </details> <details> <summary>📒 Files selected for processing (5)</summary> * `.github/workflows/deploy-docs.yml` (1 hunks) * `docs/DEPLOYMENT.md` (1 hunks) * `docs/README.md` (1 hunks) * `docs/src/index.js` (1 hunks) * `docs/wrangler.toml` (1 hunks) </details> <details> <summary>✅ Files skipped from review due to trivial changes (1)</summary> * docs/README.md </details> <details> <summary>🚧 Files skipped from review as they are similar to previous changes (1)</summary> * docs/wrangler.toml </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🪛 markdownlint-cli2 (0.18.1)</summary> <details> <summary>docs/DEPLOYMENT.md</summary> 59-59: Fenced code blocks should have a language specified (MD040, fenced-code-language) </details> </details> </details> <details> <summary>🔇 Additional comments (6)</summary><blockquote> <details> <summary>.github/workflows/deploy-docs.yml (3)</summary><blockquote> `1-16`: **LGTM! Well-configured workflow triggers and permissions.** The workflow triggers (push to main, releases, and manual dispatch) align perfectly with the deployment strategy described in the objectives. The job permissions are appropriately scoped for reading code and writing deployments. --- `18-27`: **Good use of caching for faster CI runs.** The Node.js setup with npm caching and the correct cache-dependency-path will improve workflow performance across runs. --- `29-39`: **Build steps are correctly configured.** Using `npm ci` ensures reproducible builds, and the GITHUB_TOKEN environment variable enables the data-fetching scripts to access GitHub API for releases and README content. Minor note: Line 9 contains a Japanese comment in an otherwise English workflow file, though this doesn't affect functionality. </blockquote></details> <details> <summary>docs/DEPLOYMENT.md (3)</summary><blockquote> `1-65`: **Comprehensive and accurate setup instructions.** The initial setup and manual deployment sections provide clear, step-by-step guidance that aligns perfectly with the GitHub Actions workflow configuration. The instructions for obtaining Cloudflare API tokens and configuring GitHub secrets are thorough and will help users get started quickly. --- `67-135`: **Accurate technical documentation and local development guidance.** The sections covering Cloudflare Workers Static Assets features, custom domain setup, and local development workflows are technically accurate and provide valuable guidance for both deployment and development scenarios. --- `167-173`: Cloudflare Workers Free plan allows 100,000 requests per day, confirming the documentation is accurate. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
…cript Removed the Worker script (src/index.js) as it's not needed for serving static assets only. Updated configuration to properly use Workers Static Assets without a custom Worker script. Changes: - Removed docs/src/index.js (unnecessary for static-only deployment) - Updated docs/wrangler.toml to remove 'main' and 'assets.binding' fields - Configured 'not_found_handling' for custom 404 page support - Updated DEPLOYMENT.md to reflect correct configuration - Updated README.md to remove reference to Worker entry point Correct Configuration (static assets only): ```toml name = "create-mcp-tools-docs" compatibility_date = "2024-01-01" [assets] directory = "dist" not_found_handling = "404-page" ``` Per Cloudflare docs, when deploying static assets without a Worker script: - No 'main' field needed - No 'assets.binding' field needed (only for Worker script access) - Just 'assets.directory' and optional 'not_found_handling' This aligns with the official migration guide from Pages to Workers.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
docs/README.md (4)
10-34: Add Node.js version requirement to setup instructions.The setup and build process don't mention Node.js version prerequisites. Per DEPLOYMENT.md (line 145), Node.js 20+ is recommended. Add this requirement to the setup section for clarity.
### セットアップ +**前提条件**: Node.js 20以上が必要です。 + ```bash cd docs npm install--- `39-53`: **Clarify authentication prerequisite in deployment instructions.** Lines 44-47 document the `wrangler login` step, but the condensed deployment instructions (lines 50-53) omit this prerequisite. Users attempting to run `npx wrangler deploy` without prior authentication will encounter errors. Either reference the login step or include it in the abbreviated deployment snippet. ```diff 3. ビルドしてデプロイ: ```bash +npx wrangler login npm run build npx wrangler deploy--- `35-55`: **Highlight GitHub Actions automation and clarify deployment URL discovery.** The README focuses on manual Wrangler deployment but doesn't mention that GitHub Actions automates deployment on push to main and releases (covered in DEPLOYMENT.md). For users reading README first, add a sentence about automated deployment being the recommended approach. Additionally, the deployment URL template at line 95 doesn't explain how to find the actual `<your-subdomain>` value—clarify that this matches the Worker name from wrangler.toml. ```diff ## デプロイ方法 +### 自動デプロイ（推奨） +GitHub Actionsを使用した自動デプロイが設定されています。`main`ブランチへのプッシュまたは新しいリリースの公開時に自動的にデプロイされます。詳細は `DEPLOYMENT.md` を参照してください。 +### 手動デプロイ -### Cloudflare Workers Static AssetsへのデプロイAnd for the deployment URL:
## デプロイURL -デプロイ後、以下のURLでアクセス可能： -- `https://create-mcp-tools-docs.<your-subdomain>.workers.dev` +デプロイ後、以下のURLでアクセス可能（`<your-subdomain>` は `wrangler.toml` の `name` フィールドと同じです）： +- `https://create-mcp-tools-docs.<your-subdomain>.workers.dev`Also applies to: 92-96
11-22: Reorganize instructions for clarity: consolidatecd docssetup.The setup section correctly uses
cd docsonce (line 12), which is improved from prior feedback. However, consider moving allcd docs-prefixed instructions into a single introductory note for the entire "開発" section to make it explicit that all subsequent commands assume the working directory isdocs/. This reduces ambiguity for users unfamiliar with directory context.## 開発 +All commands in this section assume you are in the `docs/` directory: ### セットアップ ```bash cd docs npm install</blockquote></details> <details> <summary>docs/DEPLOYMENT.md (1)</summary><blockquote> `100-102`: **Clarify how to find the auto-assigned Workers.dev subdomain after first deployment.** The documentation mentions the subdomain is automatically assigned but doesn't explain where users find it (e.g., in Cloudflare Dashboard, via `wrangler` output, etc.). Add a brief note to help users locate their auto-generated URL after the initial deployment. ```diff ### Workers.devサブドメイン -デプロイ後、自動的に `https://create-mcp-tools-docs.<your-subdomain>.workers.dev` でアクセス可能。 +デプロイ後、自動的に `https://create-mcp-tools-docs.<your-subdomain>.workers.dev` でアクセス可能です。`<your-subdomain>` は `wrangler.toml` の `name` フィールド値です。Cloudflare Dashboardの Workers > Overview でも確認できます。
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
docs/DEPLOYMENT.md(1 hunks)docs/README.md(1 hunks)docs/wrangler.toml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/wrangler.toml
🔇 Additional comments (2)
docs/DEPLOYMENT.md (2)
72-87: All feature claims are verified and accurate.Cloudflare Workers Static Assets requests are free and unlimited, with no additional charge to store assets, confirming the "無料" (free) claim. Static assets deliver directly without requiring a Worker script, validating the simplicity statement. The unlimited request model supports the scalability and no-traffic-limits claim.
The feature descriptions in lines 78–81 are accurate and require no changes.
180-183: The review comment references links that don't appear in the provided code snippet.The code at lines 180-183 contains only two reference links (Cloudflare Workers Static Assets and Wrangler CLI), both of which are current and correct as of November 2025. However, the review comment mentions three references, including "Astro Documentation," which is not shown in the provided snippet. Either the code snippet is incomplete, or the review comment is inaccurate about what appears at those specific lines.
The two URLs present are accurate and accessible:
- https://developers.cloudflare.com/workers/static-assets/
- https://developers.cloudflare.com/workers/wrangler/
Verify whether Astro documentation is actually referenced elsewhere in the file, or clarify the scope of the review.
Likely an incorrect or invalid review comment.
| 1. **Cloudflare API トークンを取得** | ||
| - Cloudflare Profile > API Tokens | ||
| - Create Token > "Edit Cloudflare Workers" テンプレートを選択 | ||
| - Account Resources: 該当アカウントを選択 | ||
| - Zone Resources: All zones (または特定のゾーン) | ||
| - トークンをコピー |
There was a problem hiding this comment.
🧩 Analysis chain
Verify Cloudflare API token creation steps reflect current UI.
The API token creation steps reference "Cloudflare Profile > API Tokens" which may have changed in recent Cloudflare updates. Since Cloudflare periodically updates its dashboard UI, these instructions should be verified against the current Cloudflare documentation to ensure they don't mislead users who access an updated interface.
🌐 Web query:
What is the current UI path for creating Cloudflare API tokens in 2024-2025?
💡 Result:
Current UI path (2024–2025):
-
For user API tokens: Log in to the Cloudflare dashboard → click the profile/user icon (top-right) → My Profile → API Tokens → Create Token. [1][2]
-
For account (service) API tokens: Log in to the Cloudflare dashboard → Account Home / Manage Account → API Tokens → Create Token. [1][3]
References:
[1] Cloudflare Docs — Create API token.
[2] Cloudflare Docs — Cloudflare API overview.
[3] Cloudflare Docs — Roll tokens / account-token instructions.
Update Cloudflare API token creation steps to match current UI paths.
The documentation currently states "Cloudflare Profile > API Tokens," but the current Cloudflare UI (2024-2025) requires: click the profile/user icon (top-right) → My Profile → API Tokens → Create Token. Update the documentation to reflect this more accurate navigation path to prevent user confusion with the updated dashboard interface.
🤖 Prompt for AI Agents
In docs/DEPLOYMENT.md around lines 19 to 24, update the Cloudflare API token
creation instructions to reflect the current UI navigation: instruct users to
click the profile/user icon (top-right) → My Profile → API Tokens → Create
Token, then select the "Edit Cloudflare Workers" template and configure
Account/Zone resources as described, and ensure the sentence order and labels
match the current dashboard wording so readers are not misdirected.
Fixed multiple security and configuration issues: 1. Simplified .npmignore (removed redundant entries) - Removed src/ and tsconfig.json (already handled by package.json files field) - Kept only docs/, development files, and git-related entries 2. Updated Astro site configuration - Changed site URL from placeholder to environment variable or default Workers.dev domain - Allows customization via SITE_URL env var for proper sitemap/canonical URLs 3. Added GitHub API authentication support - Added GITHUB_TOKEN support in fetch-github-data.js to avoid rate limiting - Unauthenticated: 60 requests/hour → Authenticated: 5,000 requests/hour - Added documentation in DEPLOYMENT.md about GITHUB_TOKEN setup 4. Fixed unsafe array access - Added safety checks for githubData.releases array access - Prevents build failures when releases data is missing or malformed - Both English and Japanese pages updated 5. Added XSS protection - Installed sanitize-html package - Sanitized release body HTML before rendering with set:html - Allowed only safe HTML tags (br, p, strong, em, code, etc.) - Prevents potential XSS attacks from untrusted GitHub release notes Security improvements protect against: - XSS vulnerabilities from untrusted HTML in GitHub releases - Build failures from missing/invalid GitHub data - GitHub API rate limiting issues All changes maintain backward compatibility and improve site reliability.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
.npmignore (1)
1-11: Exclusion patterns are appropriate for documentation deployment.The
.npmignorepatterns correctly exclude documentation assets, development files, and Git metadata from the npm package. While thefilesfield inpackage.jsonalready provides a whitelist approach, this explicit exclusion list adds clarity and serves as defense-in-depth.docs/DEPLOYMENT.md (1)
19-24: Verify Cloudflare API token UI navigation path.The instructions reference "Cloudflare Profile > API Tokens" for creating an API token. Previous feedback indicates the current Cloudflare UI (2024-2025) uses a different navigation: click the profile/user icon (top-right) → My Profile → API Tokens → Create Token. Please verify these instructions against the current Cloudflare dashboard to ensure users can follow them accurately.
Cloudflare API token creation current UI path 2025
🧹 Nitpick comments (1)
docs/DEPLOYMENT.md (1)
175-183: Add language identifier to fenced code block.The error message code block at line 177 is missing a language identifier, which affects rendering and syntax highlighting. While this is a minor formatting issue, it improves readability.
Based on learnings
Apply this diff:
### Wranglerのデプロイエラー -``` +```text Error: A request to the Cloudflare API failed.</blockquote></details> </blockquote></details> <details> <summary>📜 Review details</summary> **Configuration used**: CodeRabbit UI **Review profile**: CHILL **Plan**: Pro <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between 6c3bd90dccb61943318d8c8b727c773cc61d1464 and f69c84179a4fc019d3c37c1bdd2449cf51da78e8. </details> <details> <summary>⛔ Files ignored due to path filters (1)</summary> * `package-lock.json` is excluded by `!**/package-lock.json` </details> <details> <summary>📒 Files selected for processing (7)</summary> * `.npmignore` (1 hunks) * `docs/DEPLOYMENT.md` (1 hunks) * `docs/astro.config.mjs` (1 hunks) * `docs/scripts/fetch-github-data.js` (1 hunks) * `docs/src/pages/index.astro` (1 hunks) * `docs/src/pages/ja/index.astro` (1 hunks) * `package.json` (1 hunks) </details> <details> <summary>🚧 Files skipped from review as they are similar to previous changes (2)</summary> * docs/src/pages/ja/index.astro * docs/scripts/fetch-github-data.js </details> <details> <summary>🧰 Additional context used</summary> <details> <summary>🪛 markdownlint-cli2 (0.18.1)</summary> <details> <summary>docs/DEPLOYMENT.md</summary> 177-177: Fenced code blocks should have a language specified (MD040, fenced-code-language) </details> </details> </details> <details> <summary>🔇 Additional comments (5)</summary><blockquote> <details> <summary>docs/astro.config.mjs (1)</summary><blockquote> `1-14`: **LGTM! Configuration is appropriate for Cloudflare Workers deployment.** The Astro configuration correctly sets up static output with a sensible default URL for Cloudflare Workers deployment (`create-mcp-tools-docs.workers.dev`), while allowing override via the `SITE_URL` environment variable. The i18n configuration properly supports English and Japanese locales without prefixing the default locale. </blockquote></details> <details> <summary>docs/src/pages/index.astro (2)</summary><blockquote> `7-10`: **LGTM! Safe array access pattern prevents runtime errors.** The conditional check correctly guards against missing or invalid `releases` data, preventing potential runtime errors when `githubData` is unavailable or malformed. --- `207-219`: **LGTM! Releases section safely handles data and limits output.** The mapping correctly uses the safe array access pattern and limits the display to the 5 most recent releases. The use of `set:html` with the sanitized content is acceptable given the sanitization configuration (though see the separate comment about improving the `rel` attribute handling). </blockquote></details> <details> <summary>docs/DEPLOYMENT.md (1)</summary><blockquote> `1-197`: **Comprehensive deployment guide covers all necessary scenarios.** The deployment documentation is thorough and well-structured, covering automatic deployment, manual deployment methods, troubleshooting, cost considerations, and configuration details. The Japanese documentation will be valuable for the target audience. </blockquote></details> <details> <summary>package.json (1)</summary><blockquote> `37-37`: **Version 2.17.0 is current and secure.** Verification confirms that `sanitize-html@^2.17.0` is the latest available version and has no known vulnerabilities. All published security advisories (REDoS, XSS, and Information Exposure) were patched in earlier versions (2.0.0-beta, 2.7.1, 2.12.1), and version 2.17.0 is above all these thresholds. The caret versioning allows safe minor and patch updates within the 2.x range. No changes needed. </blockquote></details> </blockquote></details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
| // Sanitize HTML helper | ||
| const sanitize = (html: string | undefined) => { | ||
| if (!html) return ''; | ||
| return sanitizeHtml(html.replace(/\n/g, '<br>'), { | ||
| allowedTags: ['br', 'p', 'strong', 'em', 'code', 'pre', 'ul', 'ol', 'li', 'h1', 'h2', 'h3', 'h4', 'a'], | ||
| allowedAttributes: { | ||
| 'a': ['href', 'title', 'target'] | ||
| } | ||
| }); | ||
| }; |
There was a problem hiding this comment.
Add rel="noopener noreferrer" to allowed attributes for security.
The sanitization configuration allows the target attribute on links (line 24), but does not include rel in the allowed attributes. When external links use target="_blank", the absence of rel="noopener noreferrer" can expose the site to potential security and performance issues (tabnabbing, window.opener access).
Apply this diff to include rel in allowed attributes:
const sanitize = (html: string | undefined) => {
if (!html) return '';
return sanitizeHtml(html.replace(/\n/g, '<br>'), {
allowedTags: ['br', 'p', 'strong', 'em', 'code', 'pre', 'ul', 'ol', 'li', 'h1', 'h2', 'h3', 'h4', 'a'],
allowedAttributes: {
- 'a': ['href', 'title', 'target']
+ 'a': ['href', 'title', 'target', 'rel']
}
});
};Consider also setting a default rel value in your sanitize-html configuration or ensure all external links in GitHub release bodies include rel="noopener noreferrer" when using target="_blank".
📝 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.
| // Sanitize HTML helper | |
| const sanitize = (html: string | undefined) => { | |
| if (!html) return ''; | |
| return sanitizeHtml(html.replace(/\n/g, '<br>'), { | |
| allowedTags: ['br', 'p', 'strong', 'em', 'code', 'pre', 'ul', 'ol', 'li', 'h1', 'h2', 'h3', 'h4', 'a'], | |
| allowedAttributes: { | |
| 'a': ['href', 'title', 'target'] | |
| } | |
| }); | |
| }; | |
| // Sanitize HTML helper | |
| const sanitize = (html: string | undefined) => { | |
| if (!html) return ''; | |
| return sanitizeHtml(html.replace(/\n/g, '<br>'), { | |
| allowedTags: ['br', 'p', 'strong', 'em', 'code', 'pre', 'ul', 'ol', 'li', 'h1', 'h2', 'h3', 'h4', 'a'], | |
| allowedAttributes: { | |
| 'a': ['href', 'title', 'target', 'rel'] | |
| } | |
| }); | |
| }; |
🤖 Prompt for AI Agents
In docs/src/pages/index.astro around lines 18 to 27, the sanitizeHtml config
allows the anchor attribute "target" but omits "rel", which can enable
tabnabbing when links open in a new tab; update the sanitizeHtml configuration
to include "rel" in the allowedAttributes for 'a' (i.e., allow
['href','title','target','rel']) and optionally add a sanitize-html transform or
post-processing step to ensure external links with target="_blank" have
rel="noopener noreferrer" by default.
The sanitize-html dependency was accidentally installed in the root package.json instead of docs/package.json. This fixes that mistake. Changes: - Removed sanitize-html from root package.json (CLI tool doesn't need it) - Added sanitize-html to docs/package.json (where it's actually used) This ensures the CLI tool's dependencies remain clean and the documentation site has its own isolated dependencies.
…prompts The GitHub Actions workflow was failing with exit code 130 because the CLI was prompting for user input in a non-interactive CI environment. Changes: - Detect CI environment via process.env.CI - Skip all inquirer prompts when in CI mode - Use sensible defaults in CI (runNpmInstall=true, initGit=true, installForClaude=false) - Ensure name and description are set from defaults if not provided This fixes the broken workflow reported by the user.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/index.ts (2)
143-154: Add logging for CI-selected defaults.The CI defaults are applied silently, which could make debugging difficult in CI environments. Consider adding console output to indicate which defaults were selected.
Apply this diff to add logging:
// In CI, use defaults for any questions that were skipped if (isCI) { + console.log(chalk.cyan('Running in CI mode with defaults:')); if (!answers.name) { answers.name = path.basename(directory); + console.log(chalk.cyan(` - name: ${answers.name}`)); } if (!answers.description) { answers.description = "A Model Context Protocol server"; + console.log(chalk.cyan(` - description: ${answers.description}`)); } answers.runNpmInstall = true; answers.initGit = true; answers.installForClaude = false; // Don't try to install for Claude in CI + console.log(chalk.cyan(' - Will run npm install and git init')); }
273-275: Conditionally display next steps based on what was already executed.The "Next steps" output always suggests running
npm install(line 275), even when it was already executed (which is forced in CI mode at line 151). This could confuse users about what actions remain.Apply this diff to conditionally show next steps:
// Print next steps console.log("\nNext steps:"); console.log(chalk.cyan(` cd ${directory}`)); - console.log(chalk.cyan(" npm install")); + if (!answers.runNpmInstall) { + console.log(chalk.cyan(" npm install")); + } console.log( chalk.cyan(` npm run build ${chalk.reset("# or: npm run watch")}`), );
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
docs/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (2)
docs/package.json(1 hunks)src/index.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- docs/package.json
🔇 Additional comments (3)
src/index.ts (3)
109-139: LGTM! Prompt conditions are correctly gated for CI.The conditional logic appropriately skips interactive prompts in CI environments while still respecting command-line options. The platform check for Claude.app installation (line 123) correctly combines with the CI check.
100-154: Verify alignment between code changes and PR objectives.The PR objectives state this is about "Add documentation landing page for Cloudflare Workers deployment," but the changes in this file add CI environment support to the scaffolding tool itself. While these changes appear technically sound, they seem unrelated to the stated objective of creating documentation.
Can you clarify how these CI-related changes relate to the documentation deployment? If this PR is bundling multiple independent features (documentation site + CI support for scaffolding), consider splitting them into separate PRs for clearer change tracking and easier review.
100-101: Now let me verify the actual code in the repository to confirm what's currently implemented:The current CI detection implementation is correct and follows industry standards. The suggested refactor should not be applied.
CI systems typically set the environment variable CI as a de facto standard across popular CI services like GitHub Actions, Travis CI, CircleCI, GitLab, and others, with values set to 'true'. The CI variable is always set to 'true' when builds run in those servers.
The current code
process.env.CI === 'true' || process.env.CI === '1'correctly handles the standard CI detection patterns. The suggested refactor using!!(process.env.CI && process.env.CI !== 'false' && process.env.CI !== '0')would be overly permissive and could incorrectly treat arbitrary values (likeCI='yes'orCI='on') as indicators of a CI environment, violating the established standard.Strict string comparison is the appropriate approach for CI detection in this context.
Likely an incorrect or invalid review comment.
hideokamoto
deleted the
claude/create-docs-landing-page-01GSymTUuksUYZHApLxCMp5b
branch
2 participants
The documentation site showcases:
The site can be deployed to Cloudflare Workers as static assets
and is excluded from npm package distribution.
Summary by CodeRabbit
New Features
Chores