-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
SvelteKit SDK Roadmap #6692
Comments
I think we definitely need to make this its own package, just like the NextJS/Remix SDKs. |
Copying a few of the challenges for a SvelteKit SDK I identified so far from the GH discussion:
EDIT: Also refined what we need to instrument on client and server in the original post |
For future reference: For the routing instrumentation, I currently have a version running that uses the |
I would like to have SvelteKit support too. 👍 //From Svienna, Sentry talk. 🎉🎉🎉 |
I would be very interested in this as well. Specifically a cloudflare workers compatible implementation. Thanks for considering a SvelteKit integration though! |
are you already working with toucan-js? We have not discussed to start with native support for cloudflare to start. If we ever get around to it, best done in a way that should not be specific to any particular framework. But we are happy to gather feedback about what is and is not working, with our SDKs there and learnings from using the toucan-js package |
Hello everyone, we just released version 7.44.0 with the first alpha version of We'd really appreciate feedback, be it bug reports, UX/DX opinions, or of course thanks and praises 😄 Feel free to reach out in this thread, or in case of a bug report, please open a new issue. Thanks! |
Hi @Lms24, and thank you for this first version. I just had a look, and I have a few questions/comments (in random order). 1/ What is 2/ sentry.client.config.ts & sentry.server.config.ts doesn't have access to
3/ sentry.client.config.ts & sentry.server.config.ts doesn't have access to
4/ Sentry.init doesn't have access to if (PUBLIC_SENTRY_DSN) {
Sentry.init({
dsn: PUBLIC_SENTRY_DSN,
tracesSampleRate: 0.5,
replaysSessionSampleRate: 0.05,
replaysOnErrorSampleRate: 1.0,
release: `${dev ? 'dev' : 'prod'} - v${data.releaseCreatedAtUtc.toISOString()}`,
environment: dev ? 'development' : 'production',
integrations: [new Sentry.Replay(), new BrowserTracing()],
initialScope: (scope) => {
return scope.setExtra('DEPARTMENT', PUBLIC_DEPARTMENT)
}
})
} 5/ Limitation: manually add our wrappers to all your load Thx again & happy coding |
Hey @jycouet thanks for your feedback, really appreciate you taking a look! Let me answer your points:
It applies additional properties to the users' vite config, like adding a new plugin to inject our SDK init calls into the client and server bundles.
Our idea with wrapping the entire config is that it's easier for us to introduce and for our SDK users to consume changes. For instance, if we introduce more plugins (which we'll do once we upload source maps automatically) or add other properties to the vite config, users don't need to make these changes themselves but our wrapper takes care of this.
This is a good point, thanks for raising it. We might need to revisit the DX around intializing the SDK then. Perhaps, we just instruct folks to add the init call in
Hmm I guess this is tricky because I'm pretty sure that hooks files don't have access to that either 😅 For this I'm wondering if it is actually a good idea to use. Once we include our release creation and source maps plugin to the SvelteKit SDK, we'll be able to inject the release into the code at build time, which means you don't need to set it manually at all when initializing the SDK. So at this point I'd de-prioritize this use case if that makes sense.
So our rough idea here is to take a similar approach to what we did for NextJS. There, at build time, we load a template that imports the users'
That's good to know and something we'll need to consider. Right now, we make sure that our plugin runs first but we can of course adjust this. A general note: We're trying to keep DX for our full stack framework SDKs as similar as possible. For example, in the NextJS SDK, we also use dedicated |
Also, would be nice to bump some dep as I get
Thx |
RE |
To everyone following this thread: If you come across bugs or have specific requests, please open a new issue instead of replying here, thanks! This helps us triaging and keeping a better overview, thanks :) |
Updating form 7.49.0 -> 7.50.0 (or any thereafter) results in this error when I run
It also fails when run in production mode (e.g. Vercel). I'm puzzled no one else has seen this as my project isn't very different than most simple SvelteKit projects. I updated to the latest versions of Vite (4.3.0) and SvelteKit (1.20.2) but to no avail. |
@skylar (sorry for getting back to you only now, I was ooo) would you mind opening an issue with a minimal reproduction for this? It's also the first time that I'm hearing about this. |
Is there a timeline for supporting the Vercel edge runtime? Currently getting this error when I try to build:
|
Hi folks, I'm going to close this issue for the time being. We're currently not actively working on new SvelteKit SDK features other than fixing bugs and adding general SDK improvements. As you can see, there are still some open points in the roadmap but we have to prioritize things and currently, other tasks have higher priorities. Does this mean we won't do any of them? No! I'd love to get some stuff done once we have some time for it. There's one exception to this, which is the (Vercel) Edge runtime support. We're working on getting there. However, to work on the necessary SvelteKit-specific part, we first have to refactor some general SDK internals first. This is being tracked in #8693. Please feel free to open issues with specific bug reports or feature requests! thanks! |
Discussed in #5838
Problem Statement
There is already support for the Svelte JavaScript framework, and now that SvelteKit is also in a 1.0 stable release we should extend the support.
See: https://svelte.dev/
SvelteKit: https://kit.svelte.dev/
If you are interested in this, please react to this issue and/or leave a comment below!
Solution Brainstorm
An SDK similar to what we have for NextJS, providing support for client- and server-side error and performance monitoring.
Initial Work
Initially, we'll focus on these tasks to release the first version of the SvelteKit SDK. While this version will still require manual instrumentation, it should be enough to release and receive early feedback from the community.
The following high-level tasks will be extracted to separate issues each (if applicable) to track them individually on a more fine-grained level:
Initial Tasks
Goal: Users can add and configure the SvelteKit SDK to their project and initialize the SDK for errors, performance and Replay. At this point, fully using the SDK will require manual wrapping of data fetchers and handlers. This SDK will work with the Node SvelteKit Adapter.
Advanced Features
Once we have a basic SDK, we start looking at more advanced features. These differ from stretch goal in the sense that they have immediate high value. For example: They make usage significantly easier or increase the supported platforms in which the SDK can be used.
Tasks
load
functions #7940Goal: Users no longer need to manually add Sentry wrappers to their data fetchers and handlers. Instead, this will be done automatically at build time. Additionally, users can use the SDK not just on Node servers but also on Vercel.
Stretch Goals
If we have enough resources and time, there are a couple of cool stretch goals to take a look at:
We will likely not be able to implement all of these features from the start. That's okay. We can extract them to separate issues or implement them by demand at a later time.
Stretch Goals
Goal: The moon 🚀
Dog-fooding opportunities:
┆Issue is synchronized with this Jira Improvement by Unito
The text was updated successfully, but these errors were encountered: