Skip to content
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

Split option for client side sourcemaps #10068

Open
gtm-nayan opened this issue May 31, 2023 · 1 comment
Open

Split option for client side sourcemaps #10068

gtm-nayan opened this issue May 31, 2023 · 1 comment

Comments

@gtm-nayan
Copy link
Contributor

Describe the problem

While working on #10041, I realized that setting sourcemaps true in the vite config will set it to true for both client and server builds, which might not always be what you want. The client sourcemaps are left in the assets folder so they're accessible as any other asset without any restriction.

Describe the proposed solution

Something like config.kit.overrideClientSourcemaps: typeof vite_config.build.sourcemap and then set the value to overrideClientSourcemaps in the client build if present.

Alternatives considered

User deletes sourcemaps in the client folder after build
or #9544

Importance

nice to have

Additional Information

No response

@Lms24
Copy link
Contributor

Lms24 commented May 31, 2023

I want to share my perspective on this from the PoV of Sentry, where we need source maps to be present during the build.

(Read here as for why we need to upload users' source maps).

which might not always be what you want

I agree, it's not ideal that source maps are always generated for both, client and server, but this is how most bundlers and frameworks (e.g. NextJS) do it. I'm wondering if this is a necessary change after all.

Something like config.kit.overrideClientSourcemaps: typeof vite_config.build.sourcemap and then set the value to overrideClientSourcemaps in the client build if present.

So iiuc, this would be an opt-out option? Meaning, by default, if build: {sourcemap: true} is set, both client and server maps would be generated and only if kit.overrideClientSourcemaps would be set to false, client source maps would be omitted? If so, I think this is a fair solution. If it was opt-in, I would strongly argue against that.

The reason is that right now, our Vite plugin by default enables generation and uploading of source maps without users having to do any configuration manually (other than registering our plugin). Retaining this comfort with an opt-in mechanism in svelte.config.js would be close to impossible without serious (ugly) workarounds if possible at all.

User deletes sourcemaps in the client folder after build

This is basically what other frameworks also expect from users if they decide to generate source maps.

One thing I'm taking away from this issue (which definitely highlights valid concern) is that we should provide a better API from the Sentry SDK/Vite plugin side to delete source maps after we uploaded them, if it was our plugin that previously enabled them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants