So now I understand this problem in general, but these bugs that have been reported cannot be solved by us users because we do not have access to the core code, and these bugs are just for our awareness?

So now I understand this problem in general, but these bugs that have been reported cannot be solved by us users because we do not have access to the core code, and these bugs are just for our awareness?

@MrJs6781 Not quite, these issues aren't raised just for awareness. Next.js and Turbopack are open source, so the core code is publicly accessible, meaning anyone (including community members) can propose a fix by creating a pull request. Reporting issues with clear, minimal reproductions helps both the Next.js core team and the community identify and resolve bugs faster. Typically, the core team handles fixes, but contributions from the community are welcome.

I did some further testing and was able to pinpoint the release this broke. You can test by pinning the next.js version on the reproduction repo.

14.0.4-canary.43 is the latest working version, anything after that will produce the error.

When looking at 14.0.4-canary.44 there are two PR's that may be related:

1. side effects optimization: #58972 & turborepo:#6590 (Looks like this is most likely the cause - I did try disabling turbopackTreeShaking but that did not fix the reproduction)
2. add module tracing for client reference and next/dynamic walking: #59306
   LMK if there is anything I can do to help resolve this.

CC: @sokra

In case this helps anyone, a temporary workaround is to re-export by defining new variables.

"use server";
import { log } from "./lib";

// This doesn't work due to the bug:
// export { log as logAction };

// This works as a workaround:
export const logAction = log;