Fix/build errors and dependencies #325
Conversation
…iles, and Sanity config
WalkthroughMostly non-functional edits plus build/config updates: two library files had only trailing-newline changes; Next.js build config updates webpack callback signature, adds IgnorePlugin for Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: defaults Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
🧰 Additional context used🧠 Learnings (1)📚 Learning: 2025-12-05T02:22:28.063ZApplied to files:
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (2)
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]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
app/lib/config.ts (1)
62-75: Consider additional placeholder patterns.The validation function checks for common placeholder patterns, but could be more comprehensive.
🔎 Suggested additions to placeholder patterns
function isValidProjectId(projectId: string): boolean { if (!projectId) return false; // Check for common placeholder patterns const placeholderPatterns = [ /^your-project-id/i, /^placeholder/i, /^example/i, /^test-project/i, /^change-me/i, /^replace/i, + /^xxx/i, + /^todo/i, + /^fixme/i, + /^(my|project|id)$/i, // Single generic words ]; return !placeholderPatterns.some((pattern) => pattern.test(projectId)); }next.config.mjs (1)
98-111: Redundant Solana package aliasing on both client and server.The same Solana package aliases (
@solana-program/tokenand@solana-program/system) are set tofalsefor both server-side (lines 98-103) and client-side (lines 106-110) builds. This duplication could be simplified.🔎 Proposed refactor to eliminate duplication
// Handle Mixpanel on server-side only if (isServer) { config.externals = config.externals || []; config.externals.push({ mixpanel: "commonjs mixpanel", }); - // SERVER-SIDE: Also exclude Solana packages - config.resolve.alias = { - ...config.resolve.alias, - '@solana-program/token': false, - '@solana-program/system': false, - }; - } else { - // CLIENT-SIDE: Exclude problematic packages - config.resolve.alias = { - ...config.resolve.alias, - '@solana-program/token': false, - '@solana-program/system': false, - }; } + + // Exclude Solana packages from both client and server builds + config.resolve.alias = { + ...config.resolve.alias, + '@solana-program/token': false, + '@solana-program/system': false, + }; return config;
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (4)
app/lib/config.ts(1 hunks)app/lib/sanity-data.ts(2 hunks)next.config.mjs(5 hunks)package.json(3 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-07-23T07:30:23.720Z
Learnt from: jeremy0x
Repo: paycrest/noblocks PR: 177
File: app/utils.ts:179-196
Timestamp: 2025-07-23T07:30:23.720Z
Learning: The `normalizeNetworkName` function in app/utils.ts has been updated to be dynamic and scalable, converting any network identifier to sentence case with hyphens replaced by spaces and proper handling of acronyms like "BNB".
Applied to files:
app/lib/config.ts
📚 Learning: 2025-12-05T02:22:28.063Z
Learnt from: Dprof-in-tech
Repo: paycrest/noblocks PR: 312
File: app/page.tsx:7-11
Timestamp: 2025-12-05T02:22:28.063Z
Learning: In Next.js 15 with React 19, components using useSearchParams() cannot be statically prerendered. When app/layout.tsx has `export const dynamic = "force-static"`, MainPageContent must be dynamically imported with ssr: false to avoid "Element type is invalid" errors during build. The dynamic import pattern `dynamic(() => import("./components/MainPageContent").then(mod => ({ default: mod.MainPageContent })), { ssr: false })` is the correct solution for this scenario in the noblocks repository.
Applied to files:
next.config.mjs
🧬 Code graph analysis (1)
app/lib/sanity-data.ts (3)
app/blog/types.ts (2)
SanityPost(19-29)SanityCategory(13-17)app/lib/sanity-client.ts (1)
client(7-10)app/lib/sanity-queries.ts (4)
postsQuery(4-34)postQuery(37-64)recentPostsQuery(67-89)categoriesQuery(92-98)
🔇 Additional comments (7)
next.config.mjs (3)
2-4: LGTM! Proper CommonJS interop for ESM config file.The use of
createRequireis the correct approach for importing CommonJS modules (like webpack) in an ESM-based Next.js config file.
60-60: Reconsider the justification for excludingrate-limiter-flexiblefrom bundling. The package is a pure JavaScript library with no native dependencies and bundles well with webpack. If external packaging is needed, it should be because the application uses Node.js-specific features (such as RateLimiterRedis or RateLimiterCluster) that require server-side-only execution, not due to inherent bundling incompatibility.
82-90: Verify the root cause of ignoring .d.ts files before adding webpack configuration.Using IgnorePlugin to exclude .d.ts files is a common pattern in webpack for preventing declaration files from being bundled, but ensure this addresses an actual build issue rather than being a premature optimization. If a specific error exists, document it in the comment (e.g., "Prevents webpack from processing third-party .d.ts files that were causing bundle issues"). Otherwise, verify whether declaration files in the codebase are being incorrectly imported or if TypeScript configuration options like
skipLibCheckmight be a more appropriate solution.app/lib/sanity-data.ts (2)
33-37: Good use of Next.js caching for duplicate fetch prevention.The
getCachedPostswrapper usingunstable_cacheproperly prevents duplicate fetches within a single render while maintaining the 300-second revalidation interval.
40-54: Most calling code properly handles null/empty returns, but verify UI feedback for empty states.The data fetching functions safely return empty arrays or null on failure. However, the handling varies by usage location:
getPost()is properly checked withif (!post)guards in both call sitesgetRecentPosts()in DetailClient correctly checksrecent.length > 0before renderinggetCachedPosts()in HomeClient and Sitemap passes data without verifying empty states—confirm these components provide appropriate fallback UI when no content is availablegetCategories()similarly needs verification that HomeClient displays gracefully with no categoriesapp/lib/config.ts (1)
50-60: Clarify Sanity project ID format before sanitization logic.The function allows dashes in sanitized project IDs, but all Sanity project ID examples in official documentation (e.g., "o0o3tm7x", "abc123") contain only lowercase letters and numbers. If project IDs don't actually support dashes, the regex
/[a-z0-9]+([-][a-z0-9]+)*/should be replaced with/[a-z0-9]/. Verify against Sanity's project creation API or documentation to confirm the exact character restrictions.package.json (1)
55-55: Clarify the necessity and purpose of module interception library dependencies.The additions of
import-in-the-middleandrequire-in-the-middleare module interception libraries typically used for APM tools like OpenTelemetry or dynamic patching, but they are not referenced anywhere in the codebase. The PR description should explain why these dependencies are required to fix the stated build errors, or confirm whether they are transitive dependencies that should be installed automatically.
app/lib/sanity-data.ts
Outdated
| // Fetch all posts (returns empty array if Sanity is not configured) | ||
| export async function getPosts(): Promise<SanityPost[]> { | ||
| if (!client) { | ||
| throw new Error( | ||
| "Sanity client is not configured. Check your environment variables.", | ||
| // Return empty array instead of throwing to allow builds without Sanity | ||
| return []; | ||
| } | ||
| try { | ||
| return await client.fetch( | ||
| postsQuery, | ||
| {}, | ||
| { | ||
| next: { revalidate: 300 }, | ||
| }, | ||
| ); | ||
| } catch (error) { | ||
| // If Sanity fetch fails (e.g., invalid project ID), return empty array | ||
| console.warn("Failed to fetch Sanity posts:", error); | ||
| return []; | ||
| } | ||
| } |
There was a problem hiding this comment.
Silent failures may hide configuration issues during development.
The change from throwing errors to returning empty arrays allows builds to succeed even when Sanity is misconfigured. While this helps with build resilience, it could mask genuine configuration problems during development where you'd want immediate feedback.
Consider adding environment-specific behavior:
🔎 Proposed enhancement for development environment feedback
// Fetch all posts (returns empty array if Sanity is not configured)
export async function getPosts(): Promise<SanityPost[]> {
if (!client) {
+ const message = "Sanity client not initialized. Check NEXT_PUBLIC_SANITY_PROJECT_ID configuration.";
+ if (process.env.NODE_ENV === "development") {
+ console.error(message);
+ } else {
+ console.warn(message);
+ }
// Return empty array instead of throwing to allow builds without Sanity
return [];
}
try {
return await client.fetch(
postsQuery,
{},
{
next: { revalidate: 300 },
},
);
} catch (error) {
- // If Sanity fetch fails (e.g., invalid project ID), return empty array
- console.warn("Failed to fetch Sanity posts:", error);
+ const errorMessage = "Failed to fetch Sanity posts:";
+ if (process.env.NODE_ENV === "development") {
+ console.error(errorMessage, error);
+ } else {
+ console.warn(errorMessage, error);
+ }
return [];
}
}Apply similar changes to getPost, getRecentPosts, and getCategories.
📝 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.
| // Fetch all posts (returns empty array if Sanity is not configured) | |
| export async function getPosts(): Promise<SanityPost[]> { | |
| if (!client) { | |
| throw new Error( | |
| "Sanity client is not configured. Check your environment variables.", | |
| // Return empty array instead of throwing to allow builds without Sanity | |
| return []; | |
| } | |
| try { | |
| return await client.fetch( | |
| postsQuery, | |
| {}, | |
| { | |
| next: { revalidate: 300 }, | |
| }, | |
| ); | |
| } catch (error) { | |
| // If Sanity fetch fails (e.g., invalid project ID), return empty array | |
| console.warn("Failed to fetch Sanity posts:", error); | |
| return []; | |
| } | |
| } | |
| // Fetch all posts (returns empty array if Sanity is not configured) | |
| export async function getPosts(): Promise<SanityPost[]> { | |
| if (!client) { | |
| const message = "Sanity client not initialized. Check NEXT_PUBLIC_SANITY_PROJECT_ID configuration."; | |
| if (process.env.NODE_ENV === "development") { | |
| console.error(message); | |
| } else { | |
| console.warn(message); | |
| } | |
| // Return empty array instead of throwing to allow builds without Sanity | |
| return []; | |
| } | |
| try { | |
| return await client.fetch( | |
| postsQuery, | |
| {}, | |
| { | |
| next: { revalidate: 300 }, | |
| }, | |
| ); | |
| } catch (error) { | |
| const errorMessage = "Failed to fetch Sanity posts:"; | |
| if (process.env.NODE_ENV === "development") { | |
| console.error(errorMessage, error); | |
| } else { | |
| console.warn(errorMessage, error); | |
| } | |
| return []; | |
| } | |
| } |
🤖 Prompt for AI Agents
In app/lib/sanity-data.ts around lines 11 to 30, the current getPosts() swallows
errors and returns an empty array which can hide Sanity misconfiguration during
development; update error handling to be environment-aware: in development
(NODE_ENV === "development" or a dedicated env flag) rethrow or throw a new
error after logging so developers see failures immediately, while in production
log the error and return an empty array to keep builds resilient; apply the same
environment-aware pattern to getPost, getRecentPosts, and getCategories so all
Sanity fetch helpers surface errors during development but remain tolerant in
production.
| "react": "^19.0.1", | ||
| "react-dom": "^19.0.1" | ||
| "react-dom": "^19.0.1", | ||
| "@solana/kit": "^5.0.0" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check package.json for @solana/kit and pnpm overrides
echo "=== Checking package.json around line 116 for @solana/kit ==="
sed -n '100,130p' package.json
echo -e "\n=== Checking for pnpm overrides section in package.json ==="
cat package.json | grep -A 20 "\"pnpm\""
echo -e "\n=== Checking next.config.mjs for Solana packages ==="
cat next.config.mjs | grep -i "solana" -B 3 -A 3
echo -e "\n=== Searching for @solana/kit imports in TypeScript/JavaScript files ==="
find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.jsx" \) ! -path "*/node_modules/*" ! -path "*/.next/*" -exec grep -l "@solana/kit" {} \; | head -20Repository: paycrest/noblocks
Length of output: 1906
Remove the @solana/kit override or update to a valid version.
The pnpm override for @solana/kit": "^5.0.0" specifies a non-existent package version and is not used anywhere in the codebase. Either remove it if @solana/kit usage is not planned, or update to a valid version (current latest is 3.0.3) if it will be integrated. The related next.config.mjs excludes @solana-program/* packages, not @solana/kit, suggesting this override may have been added in error.
🤖 Prompt for AI Agents
In package.json around line 116, the pnpm override entry "@solana/kit": "^5.0.0"
references a non-existent version; either delete this override if @solana/kit is
not used, or replace it with a valid released version (e.g. "3.0.3") and run
pnpm install to update the lockfile; ensure any change is reflected in
package.json's pnpm.overrides block and remove any stray exclusions for
unrelated packages in next.config.mjs if this override was added by mistake.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (2)
app/lib/config.ts(1 hunks)package.json(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- package.json
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-07-23T07:30:23.720Z
Learnt from: jeremy0x
Repo: paycrest/noblocks PR: 177
File: app/utils.ts:179-196
Timestamp: 2025-07-23T07:30:23.720Z
Learning: The `normalizeNetworkName` function in app/utils.ts has been updated to be dynamic and scalable, converting any network identifier to sentence case with hyphens replaced by spaces and proper handling of acronyms like "BNB".
Applied to files:
app/lib/config.ts
🔇 Additional comments (3)
app/lib/config.ts (3)
62-75: LGTM!The validation logic correctly filters out common placeholder patterns and empty values. The case-insensitive regex patterns cover typical placeholder text effectively.
78-80: Consistent validation applied - past concern resolved.The client config now properly sanitizes and validates the project ID before use. This addresses the previous review comment about inconsistent validation between client and server configs. Both configs now follow the same pattern of sanitization followed by validation.
87-89: Server config validation implemented - consistency achieved.The server config now uses the same sanitization and validation pattern as the client config, directly addressing the concern raised in the previous review. Both configs will now consistently reject placeholder or invalid project IDs.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
next.config.mjs (1)
2-4: Consider using Next.js built-in webpack or direct ESM import.The
createRequirepattern works but adds complexity. Next.js webpack config functions can import webpack directly via ESM (import webpack from 'webpack') or access it through the context object, eliminating the need for CommonJS interop.🔎 Simpler alternative using direct ESM import
-import { createRequire } from "module"; - -const require = createRequire(import.meta.url); +import webpack from "webpack";Then remove line 62:
webpack: (config, { isServer }) => { - const webpack = require("webpack"); -Also applies to: 62-62
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
app/components/TransferForm.tsx(3 hunks)app/lib/config.ts(1 hunks)app/lib/sanity-data.ts(1 hunks)next.config.mjs(5 hunks)package.json(1 hunks)
✅ Files skipped from review due to trivial changes (3)
- app/lib/sanity-data.ts
- app/components/TransferForm.tsx
- app/lib/config.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- package.json
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-12-05T02:22:28.063Z
Learnt from: Dprof-in-tech
Repo: paycrest/noblocks PR: 312
File: app/page.tsx:7-11
Timestamp: 2025-12-05T02:22:28.063Z
Learning: In Next.js 15 with React 19, components using useSearchParams() cannot be statically prerendered. When app/layout.tsx has `export const dynamic = "force-static"`, MainPageContent must be dynamically imported with ssr: false to avoid "Element type is invalid" errors during build. The dynamic import pattern `dynamic(() => import("./components/MainPageContent").then(mod => ({ default: mod.MainPageContent })), { ssr: false })` is the correct solution for this scenario in the noblocks repository.
Applied to files:
next.config.mjs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build (20.x)
🔇 Additional comments (1)
next.config.mjs (1)
60-60: Remove rate-limiter-flexible from serverExternalPackages.The package is pure JavaScript without native dependencies or Node.js-specific features and does not require external handling. It works correctly when bundled by Next.js.
Likely an incorrect or invalid review comment.
| // Exclude TypeScript definition files from being processed | ||
| if (!config.plugins) { | ||
| config.plugins = []; | ||
| } | ||
| config.plugins.push( | ||
| new webpack.IgnorePlugin({ | ||
| resourceRegExp: /\.d\.ts$/, | ||
| }) | ||
| ); |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Document what specific build error this .d.ts IgnorePlugin solves.
TypeScript loaders generate .d.ts files that should be ignored in watch mode to prevent infinite watch loops, but blanket ignoring all .d.ts files in the webpack config is unusual. This IgnorePlugin will prevent legitimate TypeScript definition imports from being processed. Please add a comment explaining:
- What specific build error this was added to fix
- Which dependency triggered the issue
- Whether the root cause could be better addressed (e.g., through package resolution or reporting upstream)
Without this context, the fix appears to be masking a deeper configuration problem rather than solving the underlying issue.
🤖 Prompt for AI Agents
In next.config.mjs around lines 82 to 90, the IgnorePlugin that skips all
`.d.ts` files needs a clear comment and a safer scope: document the exact build
error it fixes (e.g., "infinite watch-loop or EMFILE/file-watcher errors caused
by <dependency-name> generating .d.ts during build"), name the dependency that
triggered the issue, and note whether this is a workaround vs. a root-cause fix;
then narrow the IgnorePlugin to only the offending paths or apply it only in
watch mode (or prefer fixing package resolution/upstream) and add the
explanatory comment describing the specific error, dependency, and recommended
long-term remediation.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
next.config.mjs (1)
82-90: Document the specific build error this IgnorePlugin solves.As flagged in a previous review, blanket ignoring all
.d.tsfiles is unusual and could prevent legitimate TypeScript definition imports from being processed. The generic comment on Line 82 doesn't explain what specific build error necessitated this plugin.Please add inline documentation that includes:
- The exact build error message or symptom (e.g., "EMFILE error", "infinite watch loop", "memory exhaustion")
- The specific dependency that triggered the issue
- Whether this is a temporary workaround or the intended long-term solution
- Consider scoping the IgnorePlugin to specific paths rather than all
.d.tsfilesWithout this context, the fix appears to mask a configuration issue rather than addressing the root cause.
#!/bin/bash # Search for dependencies that might generate .d.ts files during build echo "=== Checking for TypeScript-related build plugins ===" rg -n "ts-loader|@swc/core|esbuild|babel.*typescript" package.json || echo "No TypeScript build plugins found" echo -e "\n=== Looking for dependencies that might generate .d.ts at runtime ===" rg -n "declaration|emitDeclarationOnly" --type json || echo "No declaration generation config found" echo -e "\n=== Checking for any references to .d.ts issues in recent commits ===" git log --all --oneline --grep="d\.ts\|definition\|type.*error" -i -20 2>/dev/null || echo "Git history not available"
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
next.config.mjs(5 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: Dprof-in-tech
Repo: paycrest/noblocks PR: 312
File: app/page.tsx:7-11
Timestamp: 2025-12-05T02:22:28.063Z
Learning: In Next.js 15 with React 19, components using useSearchParams() cannot be statically prerendered. When app/layout.tsx has `export const dynamic = "force-static"`, MainPageContent must be dynamically imported with ssr: false to avoid "Element type is invalid" errors during build. The dynamic import pattern `dynamic(() => import("./components/MainPageContent").then(mod => ({ default: mod.MainPageContent })), { ssr: false })` is the correct solution for this scenario in the noblocks repository.
📚 Learning: 2025-12-05T02:22:28.063Z
Learnt from: Dprof-in-tech
Repo: paycrest/noblocks PR: 312
File: app/page.tsx:7-11
Timestamp: 2025-12-05T02:22:28.063Z
Learning: In Next.js 15 with React 19, components using useSearchParams() cannot be statically prerendered. When app/layout.tsx has `export const dynamic = "force-static"`, MainPageContent must be dynamically imported with ssr: false to avoid "Element type is invalid" errors during build. The dynamic import pattern `dynamic(() => import("./components/MainPageContent").then(mod => ({ default: mod.MainPageContent })), { ssr: false })` is the correct solution for this scenario in the noblocks repository.
Applied to files:
next.config.mjs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build (20.x)
🔇 Additional comments (2)
next.config.mjs (2)
129-137: LGTM! Development-only image source correctly restricted.The conditional inclusion of
picsum.photosonly in non-production environments is a security best practice, preventing unnecessary external image sources in production.
98-103: The Solana package aliases are correctly implemented.The client-side aliases are necessary and properly configured. Setting resolve.alias to false tells webpack to ignore a module. Verification confirms that:
- @solana-program/token is a JavaScript client for the Token program and is a direct dependency (version 0.6.0 in package.json)
- @solana-program/system is a transitive dependency pulled in by @privy-io/react-auth, which depends on both packages
Both packages are client-side dependencies used by the Privy auth library, so they correctly require
alias: falseto prevent webpack bundling them in the browser. They should not be added toserverExternalPackagessince they're only used client-side and aren't meant to be loaded at runtime on the server.
| @@ -55,6 +59,8 @@ const nextConfig = { | |||
| }, | |||
| serverExternalPackages: ["mixpanel", "https-proxy-agent", "rate-limiter-flexible"], | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify rate-limiter-flexible usage in the repository
echo "=== Checking package.json for rate-limiter-flexible ==="
if [ -f package.json ]; then
jq '.dependencies["rate-limiter-flexible"], .devDependencies["rate-limiter-flexible"]' package.json
else
echo "package.json not found"
fi
echo -e "\n=== Searching for rate-limiter-flexible imports ==="
rg -n "rate-limiter-flexible|RateLimiter" --type ts --type tsx --type js --type jsx 2>/dev/null | head -20 || echo "No imports found"
echo -e "\n=== Checking next.config.mjs for context ==="
if [ -f next.config.mjs ]; then
sed -n '55,65p' next.config.mjs
else
echo "next.config.mjs not found"
fiRepository: paycrest/noblocks
Length of output: 598
Remove unused rate-limiter-flexible dependency and from serverExternalPackages.
The package is listed in dependencies but no imports or usage were found in the codebase. While rate-limiter-flexible is a Node.js package for rate limiting, it should not be configured in serverExternalPackages if it's not actually used. Remove it from both package.json and the serverExternalPackages array in next.config.mjs to avoid unnecessary bloat.
🤖 Prompt for AI Agents
In next.config.mjs around line 60 remove "rate-limiter-flexible" from the
serverExternalPackages array and also remove the dependency from package.json;
uninstall the package (npm/yarn/pnpm remove rate-limiter-flexible), update the
lockfile by reinstalling dependencies, and run the test/build to ensure nothing
breaks after the change.
…ges and enhancing webpack configuration
5ran6
left a comment
5ran6
left a comment
There was a problem hiding this comment.
LGTM. Could you just address the comment I raised?
…lace img with Image component in TransferForm
3 participants
Description
References
Testing
Checklist
mainBy submitting a PR, I agree to Paycrest's Contributor Code of Conduct and Contribution Guide.
Summary by CodeRabbit
Chores
Style
Other
✏️ Tip: You can customize this high-level summary in your review settings.