It seems to be getting more and more common to leave your git repository completely undocumented. If you're releasing a software project on github, I want to read about it on github.
A basic README that outlines what it does, how it does it, and basic syntax - this is really easy. Table stakes, I might say. I can checkout your repo and I have everything I need to work
Don’t disagree, but technically the docs are in the same repo. Not easily consumed though.
We removed bits from the readme as it kept becoming duplicated and eventually wrong. I think that’s the usual reason folks like to avoid it. DRY and all.
It's a terrible habit. Documentation is a nonfunctional requirement. It should describe what is not obvious to someone new and the value of it. Without the conveyance of utility and purpose, all of a project's potential value goes to waste with foot-gunning accuracy.
I assume you're not talking about this company because there is no such script on spotlightjs.com (easily verifiable), and the docs are also actually in the repository:
May I suggest adding some additional context to the home page? While I heard about Sentry I find difficult to understand what Spotlight does. I might not be the intended target audience though.
I agree and find this is the case for many projects like this. I read the homepage and have no idea what the tool does and why I might find it helpful, it wasn’t until I read the inset block on the “Getting Started” page for this one that I had even an inkling what it did.
Most of these types of home page seem to be written assuming I already know what their tool does.
This seems to be a super shared point of view. I’ll admit we were a bit fire-and-forget on the homepage and definitely agree with all the feedback that we need to explain what it is better.
Is this supposed to be intended for people who are already all-in with Sentry? Or can you possibly share some insight as to where this makes sense to use vs instrumenting with an OTEL SDK?
it looks to me like it covers the same funcionality as browser developer tools
but I am also pretty sure those are going away soon, which will mean the only way to inspect websites will be using tools like this (+ WASM binary formats + google controlled web-runtime[0] means the open web is not open anymore)
Your browser's dev tools don't show you what's happening inside your server (and any downstream services) when responding to the browser's HTTP requests. Spotlight does. That's what's special about it.
What? JS isn't getting replaced by WASM. Also some quick Googling says WASM is a joint project by the W3C and multiple browser owners, and debug tools exist for it in Chrome and Firefox already
David from Sentry here. If yall have feedback around Spotlight we’d love to hear it. This is a passion project for a few of us and seemed like a natural fit for our technology, and becomes especially interesting with the service oriented world we all find ourselves in.
Hey David! Few questions: I'm slightly stuck with the Vite plugin
Currently getting this when trying to do an npm run dev:
[plugin externalize-deps] No known conditions for "./vite-plugin" entry in "@spotlightjs/sidecar" package
The plugin "externalize-deps" was triggered by this import
vite.config.ts:7:29:
7 │ import spotlightSidecar from '@spotlightjs/sidecar/vite-plugin';
Should I be telling externalize-deps to leave it alone somehow?
Also, I note the PHP SDK has gotten support for Spotlight - are there plans to do the same for the .NET SDK too?
Let me circle back on the Vite issue. Bundles are the biggest challenge when doing this turns out :)
Would you mind opening a GitHub so we can circle back there?
Regarding .NET - it’s coming to all Sentry SDKs (even mobile!). They were looking at .NET already but I’m not sure off hand what prevented its release. I’d expect our other core languages have full support in the next 60 days.
More control and far lower barrier to hack on. This actually opens up a lot of doors for us even if you ignore usability and discoverability. For example, we have a POC that pops the overlay when a server error happens, giving you a rich debug experience where otherwise you might not be able to have one.
Its related in that we (Sentry) built it, and that it uses Sentry's open source SDKs to create its payloads, but its separate in that it doesnt require Sentry's monitoring service to work.
Hopefully that helps, and definitely something that is quite tough to clarify but we are still looking to improve upon.
Feature request: documentation for running this with a Python web app. It looks to me like it should work - the Python Sentry library can presumably publish to the local Spotlight forwarder.
I don't have a npm/npx/etc build mechanism setup, so I'd appreciate instructions for running a separate web server to serve the UI, rather than running the UI integrated directly into my existing Python web application.
Yep- runs fully local! We had to make some small changes to our SDKs to support the sidecar, but a fundamental goal was that this was free software and valuable without the core Sentry service.
Its run on your local device - its just a local devserver that allows Sentry's SDKs to pipe data to it. The overlay (the Spotlight UI) then connects to the sidecar via a Server-Sent Events stream (basically a pubsub HTTP stream which operates unidirectional - think websockets but simpler). This is needed due to the distributed nature of services, but our goal is to push this abstraction into dev servers, e.g. Vite.
This doesn't seem to be it, but I always wondered if it would make sense to have an extension to the IDE that uses the aggregated data from Sentry to highlight lines of code that have caused errors or slowdowns.
A basic README that outlines what it does, how it does it, and basic syntax - this is really easy. Table stakes, I might say. I can checkout your repo and I have everything I need to work
We removed bits from the readme as it kept becoming duplicated and eventually wrong. I think that’s the usual reason folks like to avoid it. DRY and all.
Example: https://github.com/getsentry/spotlight/blob/main/packages/we...
Most of these types of home page seem to be written assuming I already know what their tool does.
but I am also pretty sure those are going away soon, which will mean the only way to inspect websites will be using tools like this (+ WASM binary formats + google controlled web-runtime[0] means the open web is not open anymore)
[0] https://thewebshowcase.withgoogle.com/bring-code-from-platfo...
Currently getting this when trying to do an npm run dev:
Should I be telling externalize-deps to leave it alone somehow?Also, I note the PHP SDK has gotten support for Spotlight - are there plans to do the same for the .NET SDK too?
I'm actually looking forward to it, I wanted to try on NuGet Trends but stopped on the first hurdle: https://github.com/dotnet/nuget-trends/pull/247
Would you mind opening a GitHub so we can circle back there?
Regarding .NET - it’s coming to all Sentry SDKs (even mobile!). They were looking at .NET already but I’m not sure off hand what prevented its release. I’d expect our other core languages have full support in the next 60 days.
Deleted Comment
Only http
It seems like it isn't, but I can't tell from looking through the website. If it's totally separate, that's a quite unfortunate namespace collision
Hopefully that helps, and definitely something that is quite tough to clarify but we are still looking to improve upon.
Also added a ticket here to track this in case other folks have thoughts: https://github.com/getsentry/spotlight/issues/243
Deleted Comment
I don't have a npm/npx/etc build mechanism setup, so I'd appreciate instructions for running a separate web server to serve the UI, rather than running the UI integrated directly into my existing Python web application.
Feel free to add a GitHub issue with more details if that’s easier!
Or even something like "npx sentry-spotlight-http-server" which starts a server running containing the UI.
Pretty cool that this is a feature. I was assuming you'd be required to use Sentry to use Spotlight.
Is the sidecar run on the server or in the client?
Added a ticket to track improving the docs here: https://github.com/getsentry/spotlight/issues/242