hckrnws

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.

a lot of "open source" companies leave their repos bare so you are forced to go onto their website where they can better track and retarget you

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:

Example: https://github.com/getsentry/spotlight/blob/main/packages/we...

Retarget you for what? "Hey you should come back and read the docs on our open source project you were interested in last week"

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.

I also have no idea what it does. "Sentry for development", so it works like sentry but the errors are streamed to localhost??

That’s a good way to think about it yeah. It’s not 1:1, and also can be extended beyond Sentry, but that was our MVP.

I don't understand the use case. If it's local, I'll just get a nice traceback and I can use the normal debugger. So what's the point of this?

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.

[0] https://github.com/open-telemetry/opentelemetry-collector-co...

Yeah it absolutely could. Our docs aren’t great here and we may need to improve the APIs but it was important for us to not couple this to Sentry.

The idea is that any data source could stream to the sidecar and at the same time consume from it with a curated panel in the UI.

If you’re interested in poking around def hop in our Discord (https://discord.gg/sentry #spotlight) and let us know your thoughts.

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)

[0] https://thewebshowcase.withgoogle.com/bring-code-from-platfo...

Why do you think they'd go away? As far as I'm aware all major browsers continue to add new functionality to their dev tools.

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.

I'd love to see this a replacement for django debug toolbar in future :D

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';

Also, I note the PHP SDK has gotten support for Spotlight - are there plans to do the same for the .NET SDK too?

Thanks for asking, created a ticket for .NET support here: https://github.com/getsentry/sentry-dotnet/issues/2955

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

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.

I'm curious. I figure you considered building the UI as a DevTools extension; why 'd you go this in-page-DOM-overlay route instead?

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.

I can't disagree at all. And this is super useful, thanks.

Does this new package impact devtools source and initiators in a way where everything is attributed to spotlight?

What’s an example concern? It shouldn’t anymore than Sentry already does

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.

https://spotlightjs.com/ doesn't work

Only http

What error are you seeing? Works over here. Its hosted on Vercel so shouldn’t be too complicated or different than most similar deployments.

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.

Isn't a tool that blocks all domains registered less than 30 days ago hugely annoying?

I guess I can see the upside in terms of helping avoid newly registered phishing sites, but I don't think I could live with the downsides.

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.

"How often do you try (deliberately) to use something so newly registered?"

Often when myself or one of my friends launches a new web project!

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.

Yeah I just came back here to say that was the culprit. It's because it's a newly registered domain.

Works on my machine.

Apologies if this is a dumb question, but is this related at all to the popular Sentry that captures stack traces and such?

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

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.

Also added a ticket here to track this in case other folks have thoughts: https://github.com/getsentry/spotlight/issues/243

Ah yes, that helps a ton! So when the doc says "Sentry" it's talking about the Sentry we all know, not a new project called Sentry. Much appreciated

The footer (now?) says created by Sentry.

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.

Would a bundled JS asset work for the UI? Eg something from a CDN?

Feel free to add a GitHub issue with more details if that’s easier!

Yeah, a CDN link would be fine - anything that means I don't have to figure out how to run "npm install" for a project which isn't using that yet.

Or even something like "npx sentry-spotlight-http-server" which starts a server running containing the UI.

Maybe the docs are not good enough for that, but you can just run

    npx @spotlightjs/spotlight

That’ll get you the sidecar but not the UI widget. I think we could:

1- serve the widget from the sidecar 2- add the CDN distro

Serving the widget from the sidecar would work great for me, then I only have to run one thing.

>Spotlight is built that you don’t need Sentry to run it

Pretty cool that this is a feature. I was assuming you'd be required to use Sentry to use Spotlight.

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.

I am not sure if I fully understand the architecture.

Is the sidecar run on the server or in the client?

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.

Added a ticket to track improving the docs here: https://github.com/getsentry/spotlight/issues/242

ok! thank you

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.

Is it compatible with Sentry API (drop in replacement)?

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).

It's made by and uses Sentry.

Why are so many software things written in node now? Seems that every new project I see, the installation begins with "npm install" :(

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.

Sorry, what does this do exactly? I have only cursory familiarity with Sentry and it's not obvious why would I want it.

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.

When's it coming to Flask? :)

It works with it but it should be made more convenient. I will have a look :)

“What sql queries did the api make that my react ui is talking to”

Makes it much easier to debug local systems during development.

Same kind of thing for errors- takes something that shows up in a console somewhere and brings it into a UI.

Will give it a spin, always looking for better debug tools, thanks!

This looks interesting! I’ll be trying it soon.

Looks interesting, but I'd rather die that npm-install anything on one of my webapps.

Spotlight has a pretty strong brand name for API dev tool - https://stoplight.io/

Could be confusion

Stoplight vs Spotlight - names are going to names at the end of the day, but I’ll tell you I’ve personally not heard of that tool :')

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.

They aren't even the same

stop vs spot

In related news, there's concern that when you shuffle the name Tesla, it ends up being Least