Docs: Source Maps page scope is errors-only; omits profiling use case

Open Beginner friendly
#17,136 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Quiet
Tech stack
javascript
Domain
documentation

Research direction

Start with the JavaScript Source Maps page linked in the issue, then compare its wording with the JavaScript Profiling page and its source maps section. Update the Source Maps documentation to cover readable error stack traces and deobfuscated profiling function names, and add the profiling cross-reference if appropriate; done means both use cases are clear to readers.

Written by the indexing model from the issue text.

Description

Summary

The Source Maps page describes source maps solely in the context of errors, stating: "Upload your source maps to Sentry to enable readable stack traces in your errors." However, the Profiling page explicitly calls out source maps as a benefit of Sentry Profiling (vs. Chrome DevTools):

Source maps — Deobfuscated function names (Sentry Profiling) vs. Minified names (Chrome DevTools)

This creates a documentation gap: a user setting up profiling who follows the source maps page would have no indication that source maps also apply to (and benefit) profiling data — deobfuscating function names in profiles, not just in error stack traces.

Scope

  • Update the Source Maps page intro and/or description to reflect that source maps benefit both errors (stack traces) and profiling (function names).
  • Optionally, add a cross-reference on the Profiling page pointing to the Source Maps setup docs.
  • No change to actual SDK behavior — this is a docs-only clarification.

References

Action taken on behalf of Prithvi Rajakumar.

Dominant language
MDX
Stars
446
Forks
1.7k
Avg merge
1d 21h
Merged PRs (30d)
312

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from getsentry/sentry-docs

All issues in getsentry/sentry-docs

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.