-
Notifications
You must be signed in to change notification settings - Fork 63
chore(deps-dev): bump next from 15.5.7 to 16.0.8 #1803
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
| "eslint-plugin-mdx": "^3.6.2", | ||
| "jsx-to-string-loader": "^1.2.0", | ||
| "next": "^15.5.7", | ||
| "next": "^16.0.8", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Next.js 16's default Turbopack conflicts with existing webpack() configuration, causing build failure.
Severity: CRITICAL | Confidence: High
🔍 Detailed Analysis
When running next build with Next.js 16.0.8, Turbopack becomes the active bundler by default. The packages/docs/next.config.js contains a custom webpack() configuration for jsx-to-string-loader. Next.js 16 intentionally aborts the build when a traditional webpack() configuration is detected alongside Turbopack, leading to an immediate build failure. The package.json scripts do not include the --webpack flag to opt out of Turbopack, nor is there a turbopack.rules configuration to replace the webpack setup.
💡 Suggested Fix
Migrate the jsx-to-string-loader configuration to Turbopack's turbopack.rules format, or add the --webpack flag to the next build script in package.json to opt out of Turbopack.
🤖 Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: packages/docs/package.json#L50
Potential issue: When running `next build` with Next.js 16.0.8, Turbopack becomes the
active bundler by default. The `packages/docs/next.config.js` contains a custom
`webpack()` configuration for `jsx-to-string-loader`. Next.js 16 intentionally aborts
the build when a traditional `webpack()` configuration is detected alongside Turbopack,
leading to an immediate build failure. The `package.json` scripts do not include the
`--webpack` flag to opt out of Turbopack, nor is there a `turbopack.rules` configuration
to replace the webpack setup.
Did we get this right? 👍 / 👎 to inform future reviews.
Reference ID: 6415171
d17e8e5 to
1315c80
Compare
Bumps [next](https://github.com/vercel/next.js) from 15.5.7 to 16.0.8. - [Release notes](https://github.com/vercel/next.js/releases) - [Changelog](https://github.com/vercel/next.js/blob/canary/release.js) - [Commits](vercel/next.js@v15.5.7...v16.0.8) --- updated-dependencies: - dependency-name: next dependency-version: 16.0.8 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
1315c80 to
ba9c199
Compare
|
Seems we have 3 options here:
|
719ad2b to
7408e9d
Compare
|
chanceaclark
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you double check when you run next build && next start, otherwise looks good! Thanks for updating these!
|
That did reveal a few issues: (I am unsure how much the 2nd one is just me blindly following commands) |


Bumps next from 15.5.7 to 16.0.8.
Release notes
Sourced from next's releases.
... (truncated)
Commits
817ee56v16.0.8b298173Update react version in cna templates (#86950)7492122v16.0.7d21259dupdate version scriptb1a04a8Update React Version (#11)aab1edcv16.0.6279f2e3bump the browserslist version to silence a warning in CI (#86625)89ccb9fv16.0.575f63f7backport fix(nodejs-middleware): await for body cloning to be properly finali...d440c75v16.0.4Most Recent Ignore Conditions Applied to This Pull Request
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)