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:
Hey I see you are interested in spotlight and 78 other things and your ip belongs to fortune 1k. May be you should buy the sentry enterprise license. Just my ads. I work on martech.
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.
Not in all cases do you get a traceback into the UI. In some cases you have to look at your terminal or console. In this case it goes straight into your browser window. But additionally it also shows you a bunch of traces going on for instrumented calls.
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?
Both. Fwiw lots of folks have yet to invest in OTel so the market is super open. We’re also trying to adjust our approach to leverage OTels community instrumentation when it makes sense. That means that ideally you’ll be able to invest in OTel if you want and we’ll just consume those spans.
The other thing to note: OTel doesn’t do everything and Sentrys error context is a big part of the value prop.
Thanks for the reply. Would the Spotlight sidecar possibly be able to run independently and consume spans emitted by the Sentry exporter[0] or some other similar flow beyond strictly exporting directly from the Sentry SDK provided by Spotlight?
This tooling looks really cool and I'd love to play around with it, but am already pretty entrenched into OTel and funneling data through the collector and don't want to introduce too much additional overhead for devs.
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.
> 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?
For anyone else in this boat, I got it working by adding "type": "module" to my package.json file. Getting Tailwind to play nice with this was a bit of a battle, and I didn't manage to figure out how to import the defaultTheme properly, but Spotlight works flawlessly and the Vite plugin auto-starts the sidecar.
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.
Mostly other devs seeing instrument.js everywhere in devtools vs. the actual source. The issue is for all envs and in development has been most problematic.
So obscuring console.log or network initiators the way Sentry currently does.
Webpack and bundlers seem to generally have this problem too. Sourcemaps help resolve when present in dev.
Both say 'Unable to connect' for me (Firefox built in page) in the UK. Which I think means the name resolved but no response. (But I'm on mobile so can't say more than that.)
The domain name is new, and those get blocked by many DNS-based ad-blocks. I use NextDNS and get the same error - spotlightjs.com is blocked (resolves to 0.0.0.0)
NextDNS calls this "Block Newly Registered Domains (NRDs)", and applies to all domains <30 days. ZScaler has something similar for corporate users, so people connecting from work might see a big red warning page.
It happens I frequently enough that I forgot it, I've used NextDNS for at least a year, and it's happened at most once before. How often do you try (deliberately) to use something so newly registered?
Frankly even most new things have older domains. (I know I'm not alone here in having domains registered for projects that may or may not ever materialise..!)
Also maybe worth saying that it's not even really about NextDNS as a tool, it's that block list or ones like it. I'm not sure if it's enabled by default or not.
Are you using NextDNS by chance? Someone reported an issue with it blocking the domain on there, but it was unclear _which_ setting was blocking it. Was also odd given its just a Vercel website and the domain (afaik) was unused prior.
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.
It leverages the sentry SDKs so not so much a replacement but something else that you can use during local development (vs sending this data to the Sentry dashboard which is a little odd in development).
In this case it makes sense: it’s a UI widget. We wrote the proxy also in Node just because you already likely needed JavaScript to install the UI component that it felt logical.
Aside, 2019 and onward JavaScript has become the largest and fastest growing ecosystem of developers.
To others feedback though there’s no reason we should force you to take a bundler running in your UI. We’re gonna fix that quickly.
It basically leverages the Sentry SDKs during development and sends them into a local UI rather than a production Sentry instance. It also shows the data in a way that's more akin to local development.
Can we stop this? There's only so many names in this world and we're going to find overlap. If you're afraid of confusing two projects that are two completely separate things just because they share the same name, instead of reading what you're using, that's a you issue, not the projects.
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