`adapter-node` breaks paths to sourcemap sources by copying files during build

[danieldiekmeier]

Describe the bug

When you turn on sourcemaps in Vite, SvelteKit will generate sourcemaps even for the server. This is great! But during the build, @sveltejs/adapter-node moves the generated files, for example from .svelte-kit/output/server/foo.js to .svelte-kit/adapter-node/foo.js, breaking the relative paths to the sources in the sourcemaps.

This is the code that moves the files:

kit/packages/kit/src/core/adapt/builder.js

Lines 207 to 209 in 51f3e66

	writeServer(dest) {
	return copy(`${config.kit.outDir}/output/server`, dest);
	}

I noticed this because I wanted to setup Sentry's new SvelteKit integration, but the sourcemaps would just not work. Sentry is actually using sorcery to try to flatten all the sourcemaps from the different steps of the build: https://github.com/getsentry/sentry-javascript/blob/41fef4b10f3a644179b77985f00f8696c908539f/packages/sveltekit/src/vite/sourceMaps.ts#L136-L139

This almost works, except that adapter-node moves the files, thus breaking the chain.

A fix could be to update the source maps while copying them. (But maybe there are better options.)

Reproduction

Repo: https://github.com/danieldiekmeier/reproduction-adapter-node-sourcemaps

pnpm i
pnpm build
diff .svelte-kit/output/server/chunks/index.js.map .svelte-kit/adapter-node/chunks/index.js.map
# nothing will be printed, which is the problem: it's the same file

Logs

No response

System Info

System:
    OS: macOS 13.3.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 303.64 MB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.13.0 - ~/.asdf/installs/nodejs/18.13.0/bin/node
    Yarn: 1.22.19 - ~/.asdf/installs/nodejs/18.13.0/bin/yarn
    npm: 8.19.3 - ~/.asdf/plugins/nodejs/shims/npm
  Browsers:
    Chrome: 113.0.5672.126
    Edge: 113.0.1774.57
    Firefox: 103.0.2
    Firefox Developer Edition: 113.0
    Safari: 16.4
    Safari Technology Preview: 16.4
  npmPackages:
    @sveltejs/adapter-node: ^1.2.4 => 1.2.4
    @sveltejs/kit: ^1.5.0 => 1.18.0
    svelte: ^3.54.0 => 3.59.1
    vite: ^4.3.0 => 4.3.8

Severity

annoyance

Additional Information

No response

[Lms24]

Hi, Sentry dev 👋

I asked about this a while ago here along with some other source maps related stuff: #9608

We would really appreciate it if this was fixed. Ideally, the source maps from the Node adapter would directly map to the actual sources and not the built files in .svelte-kit. Then we wouldn't have to flatten them at all :)

Thanks!

[iandoesallthethings]

Adding a +1 on this! It's crazy difficult to track client-side errors without it, and we're building into a custom express server that runs a ton of legacy code, so we can't afford to use anything other than adapter-node.

[iandoesallthethings]

Since this got rolled back, has anyone seen anything about when they'll reattempt the adapter-node sourcemap fix? Clientside sentry is unusable until that gets resolved :(

[Lms24]

A fix could be to update the source maps while copying them. (But maybe there are better options.)

I'm wondering if a simple option might be just changing the output path in the node adapter to match the original directory hierarchy?

[Glench]

I think this was fixed in #10041

[jindraregal]

I think this was fixed in #10041

It got reverted in 1.3.1 #10314 so it is still an issue.

[Lms24]

We would really appreciate it if this issue was bumped in priority. The current behaviour is blocking some of our users because our source maps flattening approach with sorcery fails sometimes due to faulty source maps in the chain (example: getsentry/sentry-javascript#10589).

My request would be that adapter-node either completely removes the build step or, if not possible otherwise, the source maps emitted by adapter-node just link back to the actual source files. Right now, they link to the intermediate source files in .svelte-kit which is why we need to flatten them. (more context in #9608)

Obviously, it's not ideal that the path to the source files isn't correct at the moment but at least this doesn't fully block our users.