Next + SWC appear to generate incorrect sourcemaps

[markerikson]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

    Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Pro
    Binaries:
      Node: 16.14.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.2.6-canary.2
      eslint-config-next: N/A
      react: 0.0.0-experimental-e7d0053e6-20220325
      react-dom: 0.0.0-experimental-e7d0053e6-20220325

What browser are you using? (if relevant)

N/A

How are you deploying your application? (if relevant)

Vercel, but N/A

Describe the Bug

Next generates different sourcemaps when we switch between using Babel to transpile our code, and SWC. The SWC sourcemaps are incorrect - the mapped output differs from the original source code by a few lines, causing incorrect debugging behavior.

We build https://replay.io , a time-travel debugger for JS. The Replay client uses sourcemaps on both the backend and frontend to parse and display info about the recorded application. In turn, we frequently record replays of our own client app to debug how it's working.

I've made two replays of our codebase built with Next 12.2.6-canary.2 , switching only between using Babel and SWC to transpile:

• Babel: https://app.replay.io/recording/replay-next-1226-canary2-babel--e55cb64a-aea9-400b-98d3-f3b5ad3525b7
• SWC: https://app.replay.io/recording/replay-next-1226-canary2-swc--8272ce14-288f-4076-93fb-45f22c562c8f

If you open up debugger/src/actions/event-listeners.ts in both files, you can see that the Babel file correctly maps all of the lines that were hit:

In the SWC-built version, the line hit info is off by 3-4 lines.

If you open up the sourcemap visualizer tool for both versions, the Babel version is correct:

• https://app.replay.io/recording/replay-next-1226-canary2-babel--e55cb64a-aea9-400b-98d3-f3b5ad3525b7/sourcemap/o999

and the SWC version is wrong:

• https://app.replay.io/recording/replay-next-1226-canary2-swc--8272ce14-288f-4076-93fb-45f22c562c8f/sourcemap/o995

Expected Behavior

Using SWC to compile our application would generate sourcemaps that accurately map the original source.

Link to reproduction

https://github.com/replayio/devtools/tree/bugfix/FE-434-next-sourcemaps

To Reproduce

1. Clone https://github.com/replayio/devtools
2. Check out commit replayio/devtools@61605c2 , part of the bugfix/FE-434-next-sourcemaps branch.
3. Run yarn to install
4. Use Babel to build the app: yarn build, and check the build output + sourcemaps
5. Check out the tip of the bugfix/FE-434-next-sourcemaps branch, which just disables .babelrc to use SWC for building
6. Use SWC to build the app: yarnbuild, and check the build output + sourcemaps

[kdy1]

Can you try the latest version? I think this is fixed.

[fiveable-jferg]

By "the latest version", do you mean 12.3.1, or the latest canary release? (I'm also seeing this issue with sourcemaps being sent to Sentry being incorrect; literally just updated to 12.3.1 this afternoon so will monitor, but if I need to update to canary that would be good to know.)

[kdy1]

I meant the canary

[markerikson]

Whoops, somehow I missed seeing the earlier notice. Yeah, will try tomorrow!

[markerikson]

This is still definitely broken.

Steps to reproduce:

• Clone https://github.com/replayio/devtools
• Check out branch bugfix/FE-434-next-swc-sourcemaps-busted
• yarn to install deps
• yarn build
• Open up https://evanw.github.io/source-map-visualization/ in a tab
• In a file explorer, browse down to $REPLAY_REPO/.next/static/chunk/pages/recording
• Drag [[...id]-$HASH.js and [[...id]-$HASH.js.map into the sourcemap viewer
• In the top dropdown, look around list entry 128-125 for a file named actions/box-model.ts and select it
• Observe that the sourcemapped original text and minified output do not align, such as the effect: async (action, listenerApi) => line:

For comparison, this works correctly with Babel as the compiler:

I'm attaching a zip file containing the output [[...id]].js and [[...id]].js.map files for 4 different build combinations:

• 12.2, Babel compiler + Terser
• 12.2, Babel compiler + swcminify
• 12.3.canary-32, Babel compiler (+ swcminify by default?)
• 12.3-canary.32, SWC compiler

Next Babel and SWC sourcemaps.zip

That may be useful in seeing what's different.

[kdy1]

I can't build your app because yarn failed.

❯ yarn
yarn install v1.22.19
warning Missing name in workspace at "/Users/kdy1/projects/lab/devtools/packages/markerikson-stack-client-prototype", ignoring.
[1/4] 🔍  Resolving packages...
warning Resolution field "react-is@18.2.0" is incompatible with requested version "react-is@^16.13.1"
warning Resolution field "react-is@18.2.0" is incompatible with requested version "react-is@^16.7.0"
warning Resolution field "react-is@18.2.0" is incompatible with requested version "react-is@^17.0.2"
warning @redux-devtools/app > socketcluster-client > querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
warning @redux-devtools/app > socketcluster-client > uuid@3.2.1: Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
warning Resolution field "react-is@18.2.0" is incompatible with requested version "react-is@16.9.0"
warning @svgr/webpack > @svgr/plugin-svgo > svgo > stable@0.1.8: Modern JS already guarantees Array#sort() is a stable sort, so this library is deprecated. See the compatibility table on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort#browser_compatibility
error An unexpected error occurred: "https://registry.yarnpkg.com/bvaughn-architecture-demo: Not found".
info If you think this is a bug, please open a bug report with the information provided in "/Users/kdy1/projects/lab/devtools/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

And I found that the source map you posted has sourcemap for debug build (webpack HMR)
Can you upload a new one?

[jridgewell]

Here is the [[...id]-$HASH.js and [[...id]-$HASH.js.map: sourcemap.zip

[kdy1]

Thank you!

[markerikson]

Afraid I'm busy at a conference today, but I should be back online on Monday. Please let me know if you still need something more!

[kdy1]

@markerikson Did you post the correct input/map?

This is babel version, and I'm not sure if this is correct

[markerikson]

@kdy : yeah, the zip file I attached should have sourcemaps from four different build setup variations, no other code changes between them.

I will say that our sourcemaps have been... seemingly flaky and inconsistent in general, and I'm not sure what other issues we might have with our setup.

In this case, I just know that switching from Babel to SWC definitely made things worse.

But yeah, that screenshot does look kinda broken too :)

[kdy1]

@markerikson Are you using browserslist or legacyBrowsers: false?
To fix source map issue, I have to check all transform passes but I want to focus on more widely used parts first.
The first one if typescript, but it would be nice if I know which build target is used

[markerikson]

Yeah, our current target is chrome: 95:

• next.config.js
• .babelrc
• package.json browserslist

[jridgewell]

This should be resolved with swc-project/swc#6561, though that'll need to be rolled into the next release.

[markerikson]

Sweet, thanks! I'll definitely try that out as soon as you've got it available.

[kdy1]

Fixed by #43652

[markerikson]

Thank you! We're still on Next 12 atm, but I'll try upgrading soon and see what happens.

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.