Hello!
We’re evaluating Sentry as an error tracker for JS. I just started digging in today and am impressed by some of what I’ve seen so far!
An absolute requirement for us is source map support, and it was great to find out that it is available. I’ve spent several hours trying to plug it into our application and am running into a snag that would be a blocker for adoption due to our app’s deployment model.
Our app bundles the back-end ASP.NET code with the front-end assets/JS. They are packaged and deployed together. Each customer of ours–on premises or hosted–gets a whole separate copy/instance of our application. The JS is not located on a CDN or at a central location but is served by ASP.NET/IIS using the copy deployed with the rest of that instance of the application. This boils down to virtually every URL for the same JS and source map files being different per instance/customer; they really only vary by version/release of the software.
Examples of URLs to JS or source map files:
https://pizza.example.com/Client8/assets/scripts/app.jshttps://pizza.example.com/Client32/assets/scripts/app.jshttp://sandwich.something.com/Client150/assets/scripts/app.js
In the source map documentation this is a “Assets Accessible at Multiple Origins” situation that falls into “Customer-specific domains/subdomains”.
I was hoping to use the tilde (~) prefixed path to wildcard everything that could be different. What could differ would be protocol, host, and at least one URL segment that follows. The only thing consistent is the trailing /assets/scripts/app.js. However, it appears that the tilde doesn’t work for anything past the host portion of the URL which is significant for our deployment model.
I did find this issue on GitHub that mentions a wildcard path, but from what I’ve tried it doesn’t work beyond the protocol and host of the URL.
Could someone please assist us with this?
Thank you so much for your time!
Kevin