chore: update next js to version 15 #4332
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThis pull request includes updates to several Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (1)
apps/frontend-control/package.json (1)
69-69: Approved: Added Turbo mode to dev scriptThe addition of the '--turbo' flag to the dev script is a good optimization. Turbo mode can significantly speed up the development server startup and hot module replacement (HMR) for larger Next.js applications.
Consider adding a comment in the package.json to explain the purpose of the '--turbo' flag for future maintainers. For example:
"dev": "cross-env NODE_ENV=development next dev --turbo --port 3003 # Turbo mode for faster development server",
🛑 Comments failed to post (2)
packages/markdown/package.json (1)
44-44: 💡 Codebase verification
Inconsistent Next.js version specifications detected.
The following packages specify Next.js as
"15.0.0"instead of"^15.0.0":
apps/frontend-pwa/package.jsonapps/frontend-manage/package.jsonapps/frontend-control/package.jsonapps/auth/package.jsonPlease update these to use
"^15.0.0"for consistency and to allow for minor updates.🔗 Analysis chain
LGTM: Next.js peer dependency updated correctly.
The update of the 'next' peer dependency to ^15.0.0 is in line with the PR objective of updating Next.js to version 15. This change is consistent with updates in other packages across the project.
To ensure all related packages are updated consistently, please run the following script:
To ensure consistency, please run the following script to identify packages with an exact Next.js version:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all packages using Next.js as a peer dependency have been updated to version 15. # Test: Search for Next.js peer dependency declarations across all package.json files # Expect: All occurrences should specify version ^15.0.0 rg '"next":' $(fd -e json -g '**/package.json')Length of output: 1207
Script:
# #!/bin/bash # Description: Find package.json files where Next.js peer dependency is exactly "15.0.0" without the caret. rg '"next":\s*"15\.0\.0"' $(fd -e json -g '**/package.json')Length of output: 1047
apps/frontend-pwa/package.json (1)
41-41: 💡 Codebase verification
Incompatible Dependencies Found with Next.js 15.0.0
Several
package.jsonfiles in the repository still depend on Next.js version 14.x.x, which may cause compatibility issues with the proposed upgrade to Next.js 15.0.0. Ensure all dependencies are compatible with Next.js 15 before proceeding.
apps/auth/package.jsonapps/backend-docker/package.jsonapps/docs/package.jsonapps/frontend-control/package.jsonapps/frontend-manage/package.jsonapps/frontend-pwa/package.jsonapps/func-incoming-responses/package.jsonapps/func-migration-v2-export/package.jsonapps/func-migration-v3-import/package.jsonapps/func-response-processor/package.jsonapps/lti/package.jsonapps/office-addin/package.jsonpackages/grading/package.jsonpackages/graphql/package.jsonpackages/i18n/package.jsonpackages/markdown/package.jsonpackages/next-config/package.jsonpackages/prisma/package.jsonpackages/shared-components/package.jsonpackages/transactional/package.jsonpackages/types/package.jsonpackages/util/package.json🔗 Analysis chain
Verify compatibility with Next.js 15.0.0
The upgrade to Next.js 15.0.0 is a major version change that aligns with the PR objectives. However, it's crucial to ensure that all other dependencies and the existing codebase are compatible with this new version.
Please run the following script to check for any compatibility issues:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for potential compatibility issues with Next.js 15 # Test: Look for Next.js specific APIs or configurations that might have changed rg -i 'getServerSideProps|getStaticProps|getInitialProps|next\.config\.js' # Test: Check if there are any dependencies that explicitly require Next.js 14 rg '"next"\s*:\s*"(?:~|\^)?14' package.json apps/*/package.json packages/*/package.json # Test: Look for custom server implementations fd 'server.js|server.ts' echo "Please manually review the results for any potential compatibility issues with Next.js 15."Length of output: 1142
Script:
#!/bin/bash # Description: Check for compatibility issues with Next.js 15 # Test: Look for dependencies that explicitly require Next.js 14 rg '"next"\s*:\s*"[~^]?14\.[0-9]+\.[0-9]+"' package.json apps/*/package.json packages/*/package.json # Test: Check for usage of Turbopack in development scripts rg '--turbo' package.json # Test: Search for any Next.js specific APIs that might have changed in version 15 rg -i 'getServerSideProps|getStaticProps|getInitialProps|next\.config\.js' echo "Please review the above results for any compatibility issues with Next.js 15 and the use of Turbopack."Length of output: 15349
klicker-uzh
|
||||||||||||||||||||||||||||
| Project |
klicker-uzh
|
| Branch Review |
upgrade-next
|
| Run status |
|
| Run duration | 10m 53s |
| Commit |
|
| Committer | Julius Schlapbach |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
Failures
|
0
|
Flaky
|
0
|
Pending
|
0
|
Skipped
|
0
|
Passing
|
133
|
| View all changes introduced in this branch ↗︎ | |
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (4)
apps/auth/next.config.mjs (1)
Line range hint
1-15: Summary: Successful transition to ES module syntaxThe changes in this file successfully transition the Next.js configuration to ES module syntax, which is consistent with the update to Next.js 15. The core configuration logic remains intact, ensuring that existing functionality is preserved.
As you continue updating other parts of the codebase:
- Ensure all files importing this configuration are updated to use
importsyntax.- Consider applying similar changes to other Next.js configuration files in the project for consistency.
- Update any build or deployment scripts that may be affected by this syntax change.
apps/frontend-control/next.config.mjs (2)
5-9: LGTM: Flexible configuration setupThe use of
letfornextConfigallows for the necessary reassignment later in the file. The spread operator correctly incorporates the base configuration.Consider using object destructuring for the environment variable:
let nextConfig = { ...getNextBaseConfig({ BLOB_STORAGE_ACCOUNT_URL: process.env.BLOB_STORAGE_ACCOUNT_URL, }), }This approach can make it clearer which environment variables are being used in the configuration.
12-15: LGTM: Proper conditional PWA configurationThe PWA configuration is correctly applied conditionally, avoiding its use in test environments. The usage of
withPWAInitandgetNextPWAConfigis appropriate.For improved readability, consider extracting the PWA configuration into a separate function:
const applyPWAConfig = (config) => { const withPWA = withPWAInit( getNextPWAConfig({ NODE_ENV: process.env.NODE_ENV }) ) return withPWA(config) } if (process.env.NODE_ENV !== 'test') { nextConfig = applyPWAConfig(nextConfig) }This approach encapsulates the PWA configuration logic, making the main flow easier to follow.
apps/frontend-pwa/next.config.mjs (1)
12-15: LGTM: PWA configuration applied conditionally.The PWA configuration is now correctly applied based on the environment, which is a good practice. The use of
withPWAInitand reassignment ofnextConfigis implemented correctly.Consider adding a comment explaining why PWA is not applied in the test environment for better code documentation:
// PWA is not needed in test environment if (process.env.NODE_ENV !== 'test') { // ... existing code ... }
🛑 Comments failed to post (1)
apps/auth/next.config.mjs (1)
15-15: 💡 Codebase verification
Issues Found with Configuration Exports
packages/next-config/is missing thegetNextBaseConfigexport.packages/nextjs-monorepo-workaround-plugin/is missing thePrismaPluginexport.🔗 Analysis chain
LGTM! Verify usage of this configuration in other files.
The change to
export defaultis appropriate and consistent with the transition to ES module syntax.Run the following script to verify that other files importing this configuration have been updated accordingly:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining CommonJS imports of this configuration # Test: Search for require statements importing this config file rg "require.*apps/auth/next\.config" if [ $? -eq 0 ]; then echo "Warning: Found potential CommonJS imports of the auth next.config. These may need to be updated to use import syntax." else echo "No CommonJS imports of the auth next.config found. This is good." fiLength of output: 484
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
_run_app_dependencies_macos.sh (3)
1-4: LGTM! Consider adding a check for the sync-schema.sh script.The shebang and script execution look good. The comment provides clarity on the purpose of the
sync-schema.shscript.For improved robustness, consider adding a check to ensure the
sync-schema.shscript exists before attempting to execute it. Here's a suggested addition:#!/bin/sh # copy the prisma schema for it to be available to python files +if [ ! -f "./util/sync-schema.sh" ]; then + echo "Error: sync-schema.sh not found" + exit 1 +fi ./util/sync-schema.sh
6-7: LGTM! Consider using environment variables for flexibility.The Docker Compose command looks good and starts the necessary services for the macOS environment.
For improved clarity and flexibility, consider using environment variables for service names and adding a
-dflag for detached mode. Here's a suggested refactoring:# start postgres, redis, and reverse proxy -docker compose up postgres redis_exec redis_cache reverse_proxy_macos +POSTGRES_SERVICE=${POSTGRES_SERVICE:-postgres} +REDIS_EXEC_SERVICE=${REDIS_EXEC_SERVICE:-redis_exec} +REDIS_CACHE_SERVICE=${REDIS_CACHE_SERVICE:-redis_cache} +REVERSE_PROXY_SERVICE=${REVERSE_PROXY_SERVICE:-reverse_proxy_macos} + +docker compose up -d $POSTGRES_SERVICE $REDIS_EXEC_SERVICE $REDIS_CACHE_SERVICE $REVERSE_PROXY_SERVICEThis change allows for easier customization of service names and runs the containers in detached mode, which is often preferred for development environments.
1-7: Overall, the script looks good. Consider adding error handling.The script effectively sets up the development environment for macOS by synchronizing the schema and starting the necessary Docker services.
To improve robustness, consider adding error handling for the Docker Compose command. Here's a suggested addition:
#!/bin/sh # copy the prisma schema for it to be available to python files ./util/sync-schema.sh # start postgres, redis, and reverse proxy -docker compose up postgres redis_exec redis_cache reverse_proxy_macos +if ! docker compose up postgres redis_exec redis_cache reverse_proxy_macos; then + echo "Error: Failed to start Docker services" + exit 1 +fiThis change will cause the script to exit with an error message if the Docker Compose command fails for any reason.
packages/next-config/index.js (1)
4-7: Consider removing commented out codeThe commented out
experimentalblock withesmExternals: 'loose'setting is no longer needed. To maintain code cleanliness, it's generally better to remove commented out code rather than leaving it in the codebase.If this configuration might be needed in the future, consider documenting it elsewhere, such as in a README or configuration guide.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
- _run_app_dependencies_macos.sh (1 hunks)
- apps/frontend-pwa/next.config.mjs (1 hunks)
- docker-compose.yml (1 hunks)
- packages/next-config/index.js (1 hunks)
🧰 Additional context used
🔇 Additional comments (7)
packages/next-config/index.js (1)
1-3: Verify the removal ofswcMinifypropertyThe AI summary mentions the removal of the
swcMinifyproperty, which is not visible in the provided code. This change might be related to adopting new features in Next.js 15.Please confirm if this property has been removed intentionally and if there are any implications for the build process. You may want to check the Next.js 15 migration guide for any recommendations regarding this property.
To verify the removal and its potential impact, you can run the following script:
Also applies to: 8-82
✅ Verification successful
Removal of
swcMinifyVerifiedThe
swcMinifyproperty has been intentionally removed in the upgrade to Next.js 15.0.0. There are no implications for the build process.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for swcMinify usage and Next.js version # Check if swcMinify is used anywhere in the codebase echo "Checking for swcMinify usage:" rg 'swcMinify' # Check Next.js version in package.json files echo "Checking Next.js version:" fd package.json --exec jq -r '.dependencies.next // .devDependencies.next // empty'Length of output: 258
docker-compose.yml (2)
Line range hint
1-279: Review frontend services for Next.js 15 compatibilityGiven that this PR is part of upgrading to Next.js 15, it's surprising that there are no changes to the frontend service configurations (
frontend_pwa,frontend_manage,frontend_control).Please review these services to ensure:
- They are compatible with Next.js 15.
- Any new environment variables or configuration changes required by Next.js 15 are properly set.
- Build and runtime configurations are updated if necessary.
It might be helpful to consult the Next.js 15 upgrade guide for any required changes in Docker environments.
To check for any Next.js related environment variables in the frontend services, run:
#!/bin/bash # Check for Next.js related environment variables in frontend services grep -n "frontend_" docker-compose.yml -A 10 | grep -E "environment:|NEXT_|NODE_"
20-35: Clarify the need for a separate macOS reverse proxy serviceThe addition of
reverse_proxy_macosraises several concerns:
- Redundancy: This service is identical to
reverse_proxy_docker, which may lead to maintenance overhead.- Port conflicts: Both services are attempting to use the same ports (80 and 8080), which could cause issues.
- Naming convention: Platform-specific service names might not be ideal in a containerized environment.
- Context: The relationship between this change and the Next.js upgrade to version 15 is not clear.
Could you please clarify:
- Why is a separate macOS service necessary?
- How will port conflicts be avoided?
- Is this change directly related to the Next.js upgrade?
Consider using a single, configurable reverse proxy service that can adapt to different environments if platform-specific behavior is required.
To check for potential port conflicts, run:
apps/frontend-pwa/next.config.mjs (4)
1-2: Imports updated to ES module syntax successfullyThe import statements are correctly updated to use ES module syntax, aligning with the move to Next.js 15.
4-8: Configuration initialization is correctly implementedThe
nextConfigobject is properly initialized usinggetNextBaseConfig, incorporating the necessary environment variables.
10-15: Conditional PWA configuration is applied appropriatelyThe PWA configuration is conditionally applied when
NODE_ENVis not'test', ensuring that PWA features are excluded during testing environments.
17-17: Export statement updated to ES module syntaxThe configuration is correctly exported using
export default, consistent with ES module standards.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
apps/auth/Dockerfile (1)
Line range hint
1-64: Add stage purpose comments for better maintainability.Consider adding comments before each stage to explain its purpose. This would make the Dockerfile more maintainable, especially given its multi-stage nature.
+# Base stage: Sets up the Node.js environment FROM docker.io/library/node:20.17.0-alpine AS base ARG NODE_ENV production ENV NODE_ENV $NODE_ENV +# Builder stage: Prepares the application for building FROM base AS builder WORKDIR /app +# Installer stage: Installs dependencies and builds the application FROM base AS installer WORKDIR /app +# Runner stage: Final stage that runs the application FROM base AS runner WORKDIR /appapps/frontend-manage/Dockerfile (1)
Line range hint
23-24: Add explicit copy of next.config.mjs in the installer stage.The Next.js build process requires the configuration file, but it's not explicitly copied in the installer stage. While it might work due to the full copy from the builder stage, it's better to be explicit.
Add the following line after the existing COPY commands in the installer stage:
COPY --from=builder /app/out/json/ . COPY --from=builder /app/out/pnpm* . +COPY --from=builder /app/out/full/apps/frontend-manage/next.config.mjs ./apps/frontend-manage/
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (4)
- apps/auth/Dockerfile (1 hunks)
- apps/frontend-control/Dockerfile (1 hunks)
- apps/frontend-manage/Dockerfile (1 hunks)
- apps/frontend-pwa/Dockerfile (1 hunks)
🔇 Additional comments (5)
apps/auth/Dockerfile (1)
51-51: Verify the Next.js configuration file.The change from
next.config.jstonext.config.mjsaligns with the Next.js 15 upgrade. However, let's verify the existence and syntax of the new configuration file.✅ Verification successful
Let me gather more information about the content of the next.config.mjs file to ensure it's properly structured.
Next.js configuration file change is valid and properly structured
The
next.config.mjsfile exists and is correctly structured with:
- Proper ES module syntax using
importstatements- Type annotations for Next.js configuration
- Valid configuration object with webpack customization
- Correct
export defaultstatement🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence and syntax of next.config.mjs # Test 1: Check if the new config file exists fd -t f "next.config.mjs" apps/auth/ # Test 2: Verify ES module syntax in the config file rg -l "export default|export const" apps/auth/next.config.mjsLength of output: 152
Script:
#!/bin/bash # Check the content of next.config.mjs to verify proper ES module syntax and configuration cat apps/auth/next.config.mjsLength of output: 436
apps/frontend-control/Dockerfile (1)
57-57: Confirm Next.js configuration file extension change.The change from
next.config.jstonext.config.mjsaligns with Next.js 15's move towards native ES modules. The file copying and permissions are correctly configured.Let's verify the consistency of Next.js configuration files across all applications:
✅ Verification successful
Based on the shell script results, I can now generate the final response since we have clear evidence that:
- There are no remaining
next.config.jsfiles in the apps directory- All Next.js applications (
auth,frontend-control,frontend-manage,frontend-pwa) consistently usenext.config.mjs✓ Next.js configuration file extension change is consistent across all apps
The migration from
next.config.jstonext.config.mjshas been consistently applied across all Next.js applications in the repository. No legacy.jsconfiguration files remain, confirming that the change aligns with Next.js 15's ES modules requirements.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining .js Next.js config files that should be .mjs # and verify that all apps have been updated consistently # Search for any next.config.js files that might need updating echo "Checking for any remaining next.config.js files:" fd "next.config.js$" apps/ # Search for next.config.mjs files to confirm consistent adoption echo -e "\nVerifying next.config.mjs files exist in all Next.js apps:" fd "next.config.mjs$" apps/Length of output: 433
apps/frontend-manage/Dockerfile (2)
Line range hint
29-40: Environment configuration looks good!The environment setup is properly configured with:
- All necessary Next.js environment variables defined as build args
- Telemetry correctly disabled in both stages
Also applies to: 71-72
58-58: Verify Next.js configuration file consistency across the codebase.The change from
next.config.jstonext.config.mjsaligns with Next.js 15's move towards native ES modules. However, we should ensure this change is consistent across all Next.js applications in the monorepo.Let's verify the configuration file naming across all Next.js applications:
✅ Verification successful
Based on the shell script results, I can now provide a final response as we have comprehensive information about the Next.js configuration files across the codebase:
Next.js configuration file migration is complete and consistent
The verification shows that:
- No
next.config.jsfiles remain in the codebase- All Next.js applications (auth, frontend-control, frontend-manage, frontend-pwa) are using
next.config.mjs- The same applications have been upgraded to Next.js 15 as confirmed by their package.json files
The change in
apps/frontend-manage/Dockerfileis consistent with the codebase-wide migration to.mjsconfiguration files.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining next.config.js files and verify .mjs adoption # Test 1: Search for any remaining next.config.js files echo "Checking for any remaining next.config.js files:" fd "next.config.js$" # Test 2: Verify .mjs adoption in all Next.js apps echo -e "\nVerifying .mjs adoption in Next.js apps:" fd "next.config.mjs$" # Test 3: Identify Next.js apps by searching for next dependency in package.json echo -e "\nIdentifying Next.js applications:" fd "package.json$" --exec rg -l '"next":\s*"15' {}Length of output: 654
apps/frontend-pwa/Dockerfile (1)
60-60: LGTM! Necessary change for Next.js 15 compatibility.The change from
next.config.jstonext.config.mjsis required as Next.js 15 mandates ES modules for configuration files.Let's verify the configuration file exists and check consistency across other Dockerfiles:
✅ Verification successful
All Next.js applications consistently use next.config.mjs
The verification confirms:
- The
next.config.mjsfile exists inapps/frontend-pwa/- All Next.js applications in the monorepo (
frontend-pwa,frontend-control,frontend-manage, andauth) consistently usenext.config.mjsin their Dockerfiles🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify next.config.mjs exists and check other Dockerfiles for similar updates # Test 1: Check if next.config.mjs exists echo "Checking for next.config.mjs..." fd "next.config.mjs" apps/frontend-pwa # Test 2: Check other Dockerfiles for consistent updates echo -e "\nChecking other Dockerfiles for next.config.mjs..." rg "COPY.*next\.config\." apps/*/DockerfileLength of output: 926
|
Summary by CodeRabbit
Release Notes
New Features
nextframework version across multiple applications and packages to enhance performance and compatibility.Bug Fixes
EvaluationConfusioncomponent, enhancing user interaction and data handling.Documentation
nextframework in various packages.