Fix the four templates failing the automated health check - #441
Conversation
commerce-kit-store: declare the @tanstack/react-query peer the commerce SDK needs and migrate lint to the Next 16 flat ESLint setup drift-hello-world: build with webpack to match the template's webpack config and pin a single @solana/web3.js across the Drift SDK tree zk-compression-airdrop: commit key-free example configs so fresh checkouts build, the app reads the RPC endpoint from env and the setup script never writes secrets to tracked files pinocchio-counter: pin the codama packages to the last versions that work together, an upstream regression in @codama/nodes 1.5.0 breaks client generation for empty instruction structs
Greptile SummaryThis PR repairs clean-install health checks for four templates.
Confidence Score: 3/5The PR should not merge until the publicly accessible credentialed RPC proxy is protected from unauthorized quota consumption. The original browser disclosure of RPC_ENDPOINT is fixed, but the replacement rewrite still forwards arbitrary unauthenticated requests through the deployment's Helius endpoint, allowing external callers to spend its quota. Files Needing Attention: community/zk-compression-airdrop/next.config.ts Important Files Changed
Sequence DiagramsequenceDiagram
participant Browser
participant Next as Next.js deployment
participant RPC as Helius RPC
Browser->>Next: POST /api/rpc (JSON-RPC)
Next->>RPC: Forward request using RPC_ENDPOINT
RPC-->>Next: JSON-RPC response
Next-->>Browser: JSON-RPC response
Reviews (7): Last reviewed commit: "chore: regenerate lockfile for codama re..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const rpcEndpoint = process.env.RPC_ENDPOINT | ||
| if (!rpcEndpoint) { | ||
| throw new Error('RPC_ENDPOINT environment variable not set. Add it to .env.local (see README).') | ||
| } | ||
| const rpc = createRpcConnection(rpcEndpoint) |
There was a problem hiding this comment.
When a deployment sets RPC_ENDPOINT to a Helius URL containing its API key, this client hook consumes the value through the next.config.ts env mapping, which embeds the complete endpoint in browser-delivered JavaScript and lets every visitor extract and reuse the credential.
How this was verified: The client-marked hook reads process.env.RPC_ENDPOINT, and the existing Next configuration exports that variable through its client-inlined env mapping.
…xplicit Regenerates the root pnpm lockfile for the commerce-kit-store react-query addition so the frozen lockfile install in CI passes. Renames the airdrop rpc variable to NEXT_PUBLIC_RPC_ENDPOINT so the browser exposure is explicit per Next convention and documents that this devnet demo embeds its credentials in the client bundle.
|
Want your agent to iterate on Greptile's feedback? Try greploops. |
…sers The airdrop client now calls a same-origin /api/rpc endpoint and a rewrite in next.config.ts forwards it to RPC_ENDPOINT on the server. Verified at runtime with a canary key: the proxy forwards requests and the key appears in no client chunk. DEV_WALLET remains browser embedded by design and the README now says so explicitly.
| source: '/api/rpc', | ||
| destination: process.env.RPC_ENDPOINT ?? 'https://api.devnet.solana.com', |
There was a problem hiding this comment.
When an unauthenticated visitor sends arbitrary JSON-RPC requests to /api/rpc, this rewrite forwards them to the credential-bearing Helius endpoint without authentication, rate limiting, or method restrictions, allowing the visitor to consume the deployment's quota or exercise methods enabled for that credential while the key remains hidden.
There was a problem hiding this comment.
True, and it is inherent to any proxy in front of a keyed endpoint, including the Cloudflare proxy Helius themselves recommend. The tradeoff is deliberate: an open same-origin proxy is strictly better than the key in the browser bundle, abuse requires hitting the live deployment and stops when it goes down, while an extracted key is reusable anywhere forever. For a devnet demo on a free tier key the blast radius is the demo's own quota. The README now documents this explicitly and tells deployers to add rate limiting or auth before pointing the proxy at quota that matters
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Upstream released @codama/renderers-js 1.7.1 with the optional fields fix after our report (codama-idl/renderers-js#168), so the version pins are no longer needed. Bumps the renderer floor to ^1.7.1 and drops the npm, yarn, and pnpm override blocks.
pnpm-lock.yaml was stale after bumping @codama/renderers-js to ^1.7.1 in kit/pinocchio-counter; regenerated with pnpm 10.5.2 (CI's pinned version). Removed entries are the dropped old dependency chain. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
This pull request has been automatically marked as stale because it has not had any activity for 7 days. It will be closed in 7 days if no further activity occurs. If you believe this PR is still relevant, please add a comment or push new commits to keep it open. Thank you for your contributions! |
|
I reviewed the PR. I would not approve it yet for two reasons:
Once the branch is rebased and the RPC proxy decision is resolved, I can re-review. |
|
This pull request has been automatically marked as stale because it has not had any activity for 7 days. It will be closed in 7 days if no further activity occurs. If you believe this PR is still relevant, please add a comment or push new commits to keep it open. Thank you for your contributions! |
2 participants
What
Fixes the four templates that fail a clean
npm install && npm run ciin a fresh checkout. Each fix is the smallest change that makes the template build again.Fixes
community/commerce-kit-store
The commerce SDK expects
@tanstack/react-queryas a peer but the template never declared it, so the build failed with module not found. Declared it, and migrated lint to the flat ESLint setup sincenext lintno longer exists in Next 16.community/drift-hello-world
Next 16 builds with Turbopack by default, but this template ships a webpack config (needed for the Drift SDK's node builtins), so the build hard errored. The build script now passes
--webpack, matching the dev script. Also pinned a single@solana/web3.jsacross the tree because the Drift SDK pins an older exact version, which installed two incompatible copies ofConnection.community/zk-compression-airdrop
The page statically imports two JSON configs that are generated by the setup script and gitignored, so fresh checkouts could not build. Committed key free example configs and moved the RPC endpoint out of the config file entirely. The browser now calls a same-origin
/api/rpcproxy thatnext.config.tsrewrites toRPC_ENDPOINTon the server, so a Helius api key never lands in a commit or in the browser bundle. The proxy tradeoff is documented in the README.kit/pinocchio-counter
Client generation crashed because the 1.x line of
@codama/renderers-jsreads structfieldsunguarded while newer@codama/nodesomits the key for empty structs, so every fresh install resolved a broken combination. We reported it upstream (codama-idl/renderers-js#168) and the maintainer released a patched1.7.1the same day. This PR bumps the renderer floor to^1.7.1, no version pins needed.Testing
Each template verified the same way the health check runs: copied to a fresh temp dir, clean install,
npm run ci. All four pass, including codama client generation for pinocchio-counter on both the npm and pnpm install paths.