lint: Enable rule to ban unexplained console.error calls

[plibither8]

This PR is completes https://github.com/sourcegraph/sourcegraph/issues/26582 and builds upon this PR in the codemod repo.

---

This PR:

1. Enables warning for the no-unexplained-console-error eslint rule created here
2. Logs to console the exceptions that were passed to Sentry through Sentry.captureException in development mode.

Test plan

Manually checked for warnings created by eslint VS Code extension when console.error calls are uncommented.

App preview:

• Web
• Storybook

Check out the client app preview documentation to learn more.

[plibither8]

The eslint step in the buildkite check is expectedly failing, since it is dependent on this PR to be merged first and uploaded to npm.

[valerybugakov]

Awesome! Left a couple of questions and curious to hear what you think of them.

[valerybugakov]

What do you think about reusing the SDK configuration between these two calls if we need both of them?

For now, they are lightweight, but we might use more configuration fields (e.g., integrations) that can affect beforeSend behavior. Having inconsistent Sentry logic depending on flags might be confusing.

[valerybugakov]

To ease the debugging of errors logged via Sentry.captureException in the development environment, we may want to introduce a utility that encapsulates internal implementation details (e.g., what service do we use for error tracking, when is it available, when to output to the console). Then consumers would be able to use it without extra safety checks like in the ErrorBoundary component.

UPD: thinking a bit more about this it's a good case for introducing a generalized logger service that could encapsulate error tracking, debug logs, telemetry service, etc. We can discuss this idea and consider introducing it in one of the follow-up PRs.

const logger = useLogger()

logger.error(error, { additionalDetails: true })
logger.debug('Something awesome happened!', { additionalDetails: true })

[valerybugakov]

We might not have the Sentry global variable in the development environment, and I see that it's not clear from the type defined above. We can change it to:

declare global {
    const Sentry: SentrySDK | undefined
}

Currently it's loaded only when SOURCEGRAPHDOTCOM_MODE === true.

[valerybugakov]

Could we leave a comment explaining why we need to log errors here to the console, as the new ESLint rule suggests?

[eseliger]

As part of #wg-delete-week I am going to close this PR. If it’s still needed, feel free to reopen and restore the branch.