Issue Station
Sign In
Tools hereToolbox

nextjs - ✅(Solved) Fix bitshift assignement in conditional broken in turbopack [5 pull requests, 5 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
vercel/next.js#85474•Fetched 2026-04-08 02:15:31
View on GitHub
Comments
5
Participants
3
Timeline
21
Reactions
0
Author
hayeshayes
Participants
github-actions[bot]github-actions[bot]hayeshayestimneutkenstimneutkens
Assignees
bgwbgw
Timeline (top)
commented ×5cross-referenced ×5referenced ×4labeled ×3

Fix Action

Fixed

PR fix notes

PR #639: [bcs] work around turbopack bug that breaks uleb128 in next@16

Description (problem / solution / changelog)

Description

fixes #635

related issue: https://github.com/vercel/next.js/issues/85474

Test plan

How did you test the new or updated feature?

AI Assistance Notice

Please disclose the usage of AI. This is primarily to help inform reviewers of how careful they need to review PRs, and to keep track of AI usage across our team. Please fill this out accurately, and do not modify the content or heading for this section!

  • This PR was primarily written by AI.
  • I used AI for docs / tests, but manually wrote the source code.
  • I used AI to understand the problem space / repository.
  • I did not use AI for this PR.

Changed files

  • .changeset/rich-clowns-pump.md (added, +5/-0)
  • packages/bcs/src/uleb.ts (modified, +2/-1)

PR #85478: Turbopack: Fix compound assignment expression evaluation

Description (problem / solution / changelog)

fixes #85474

Previously, the analyzer treated all assignment expressions the same way, evaluating them as their right-hand side value. This was incorrect for compound assignments (+=, -=, *=, |=, >>=, etc.), which compute a new value based on both the left and right operands.

This commit distinguishes between simple assignments (=) and compound assignments. Simple assignments continue to evaluate to the right-hand side, while compound assignments are now properly marked as unknown values with side effects.

Also adds tests for compound assignments in conditionals, covering bitshift operations (>>=, <<=, >>>=) and bitwise operations (|=, &=, ^=) with both numbers and bigints.

<!-- Thanks for opening a PR! Your contribution is much appreciated. To make sure your PR is handled as smoothly as possible we request that you follow the checklist sections below. Choose the right checklist for the change(s) that you're making: ## For Contributors ### Improving Documentation - Run `pnpm prettier-fix` to fix formatting issues before opening the PR. - Read the Docs Contribution Guide to ensure your contribution follows the docs guidelines: https://nextjs.org/docs/community/contribution-guide ### Fixing a bug - Related issues linked using `fixes #number` - Tests added. See: https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ### Adding a feature - Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas) - Related issues/discussions are linked using `fixes #number` - e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs) - Documentation added - Telemetry added. In case of a feature if it's used or not. - Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md ## For Maintainers - Minimal description (aim for explaining to someone not on the team to understand the PR) - When linking to a Slack thread, you might want to share details of the conclusion - Link both the Linear (Fixes NEXT-xxx) and the GitHub issues - Add review comments if necessary to explain to the reviewer the logic behind a change ### What? ### Why? ### How? Closes NEXT- Fixes # -->

Changed files

  • turbopack/crates/turbopack-ecmascript/src/analyzer/graph.rs (modified, +4/-1)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/react-dom-production/graph-explained.snapshot (modified, +13/-5)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/react-dom-production/resolved-effects.snapshot (modified, +69/-33)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/react-dom-production/resolved-explained.snapshot (modified, +11/-5)
  • turbopack/crates/turbopack-tests/tests/execution/turbopack/basic/compound-assign-in-conditional/input/index.js (added, +69/-0)

PR #9098: fix(bcs): work around turbopack bug that breaks uleb128 in next@16

Description (problem / solution / changelog)

Description of change

Following the approach from https://github.com/MystenLabs/ts-sdks/pull/639

Links to any relevant issues

related issue: https://github.com/MystenLabs/ts-sdks/issues/635 https://github.com/vercel/next.js/issues/85474

How the change has been tested

Describe the tests that you ran to verify your changes.

Make sure to provide instructions for the maintainer as well as any relevant configurations.

  • Basic tests (linting, compilation, formatting, unit/integration tests)
  • Patch-specific tests (correctness, functionality coverage)
  • I have added tests that prove my fix is effective or that my feature works
  • I have checked that new and existing unit tests pass locally with my changes

Change checklist

Tick the boxes that are relevant to your changes, and delete any items that are not.

  • I have followed the contribution guidelines for this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation

Changed files

  • .changeset/uleb128-next16.md (added, +5/-0)
  • sdk/bcs/src/uleb.ts (modified, +2/-1)

PR #85589: turbopack: fix(analyzer): The value of an assign expr is only equal to the RHS in simple assignments

Description (problem / solution / changelog)

This might fix https://github.com/vercel/next.js/issues/85474

https://tc39.es/ecma262/#sec-assignment-operators-runtime-semantics-evaluation

The assign expression only evaluates to the RHS when it's a simple assignment (lhs = rhs). This is nice when it works because rhs can often be evaluated to an exact value.

If it's an assignment operator (lhs += rhs), we'd need to evaluate it as the new value of lhs. In cases where lhs is a pattern or a member expression, it's easier to just bail out.

Changed files

  • turbopack/crates/turbopack-ecmascript/src/analyzer/graph.rs (modified, +5/-1)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/assign/graph-explained.snapshot (modified, +10/-6)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/assign/graph.snapshot (modified, +31/-5)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/assign/input.js (modified, +8/-7)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/assign/resolved-explained.snapshot (modified, +12/-6)

PR #85593: Turbopack: Fix compound assignment expression evaluation (#85478)

Description (problem / solution / changelog)

Migrated from https://github.com/vercel/next.js/pull/85478 into this non-fork because we had some issues with our CI infra that should be fixed going forward: https://vercel.slack.com/archives/C04KC8A53T7/p1761862171772939

fixes #85474

Previously, the analyzer treated all assignment expressions the same way, evaluating them as their right-hand side value. This was incorrect for compound assignments (+=, -=, *=, |=, >>=, etc.), which compute a new value based on both the left and right operands.

This commit distinguishes between simple assignments (=) and compound assignments. Simple assignments continue to evaluate to the right-hand side, while compound assignments are now properly marked as unknown values with side effects.

Also adds tests for compound assignments in conditionals, covering bitshift operations (>>=, <<=, >>>=) and bitwise operations (|=, &=, ^=) with both numbers and bigints.

Changed files

  • turbopack/crates/turbopack-ecmascript/src/analyzer/graph.rs (modified, +4/-1)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/react-dom-production/graph-explained.snapshot (modified, +13/-5)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/react-dom-production/resolved-effects.snapshot (modified, +69/-33)
  • turbopack/crates/turbopack-ecmascript/tests/analyzer/graph/react-dom-production/resolved-explained.snapshot (modified, +11/-5)
  • turbopack/crates/turbopack-tests/tests/execution/turbopack/basic/compound-assign-in-conditional/input/index.js (added, +69/-0)

Code Example

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Aug 11 21:16:21 PDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 24.7.0
  npm: 11.5.1
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 16.0.0 // Latest available version is detected (16.0.0).
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.9.2
Next.js Config:
  output: N/A
RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/hayes/turbopack-assigment-in-conditional/blob/main/src/app/api/bug/route.ts

To Reproduce

Current vs. Expected behavior

Current: All keys in response should result in 0 or 0n Expected: bitshift assignments inside the conditional of an if statement do not correctly modify the variable

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.6.0: Mon Aug 11 21:16:21 PDT 2025; root:xnu-11417.140.69.701.11~1/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 24.7.0
  npm: 11.5.1
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 16.0.0 // Latest available version is detected (16.0.0).
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.9.2
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Vercel (Deployed), Other (Deployed)

Additional context

No response

extent analysis

TL;DR

The issue with bitshift assignments inside conditional statements in Turbopack can be addressed by verifying the compilation and execution of the code, potentially involving adjustments to the Turbopack configuration or the code itself to ensure correct handling of bitwise operations.

Guidance

  • Review the Turbopack configuration to ensure it is set up to correctly handle bitwise operations within conditional statements.
  • Verify that the next and turbopack versions are compatible and up-to-date, as issues might be resolved in newer versions.
  • Inspect the compiled JavaScript code to see how the bitwise operations are being translated and executed, which might reveal discrepancies between expected and actual behavior.
  • Consider creating a minimal reproducible example outside of the Next.js environment to isolate if the issue is specific to Turbopack or a more general JavaScript compilation issue.

Example

No specific code example can be provided without altering the original codebase, but checking the compilation output of the route.ts file might offer insights into how Turbopack handles the bitwise operations.

Notes

The exact solution depends on the specifics of how Turbopack handles bitwise operations within conditional statements, which might require deeper investigation into Turbopack's documentation or source code.

Recommendation

Apply workaround: Given the information, it seems more practical to apply a workaround, such as restructing the code to avoid bitwise operations within conditional statements or adjusting the Turbopack configuration, rather than waiting for a potential fix in a future version.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#generation error#database connection#vector store#embedding generation

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING