feat(various): Apply debug guard to logger everywhere #4698
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This applies the
isDebugBuild()
guard (which allows logging code to be stripped when creating minified bundles) to a number of aspects of the logger:All calls to the logger now have the guard. While it's true that not all log statements appear in spots which currently have any chance of making it into a bundle, applying the guard universally reduces cognitive load for both folks reading and writing our code, and future-proofs (or, perhaps more accurately, new-bundling-situation-proofs) all of our logging.
The
Sentry.init()
optiondebug
now only enables the logger if we're in a debug build. This allows us to remove any reference to the logger in non-debug builds, making it able to be dropped from the code. A warning message has also been added to non-debug builds, because someone usingdebug
is presumably doing so because they actually do want logging.The
logger
singleton is only attached toglobal.__SENTRY__
if we're in a debug build. This makeslogger.ts
side-effect-free in non-debug builds, allowing it to be treeshaken freely.Note that because the return value of
isDebugBuild()
is alwaystrue
(absent intervention by a bundler), it's safe to use everywhere without changing any current behavior.Finally, all preexisting
if
-block versions of the check are converted to short-circuit versions, for consistency and concision.NOTE: The bundle size increases here come because this PR is part of a series refactoring the way we strip logging when creating minified bundles, after the old way has been taken out but before the new way has been phased in. Once all PRs have been merged, there should be a net savings.