Sentry-javascript: What is the deal with wrapConsoleMethod() ?

@grapho – console statements are collected and passed as breadcrumbs.

I can see how it can be irritating that, as a result of instrumenting console.log, the URL in devtools will no longer take you to the original log statement in your source. We could make instrumenting console.log optional. Or alternatively, introduce Raven.log as an alternative API for recording your own breadcrumbs.

@benvinegar I promise I am not irritated... if there is a way i can use the breadcrumbs or an equivilant api in a development setting.. place of console.log, i would love to know how?

i could get used to placing breakpoints and debugger statments instead.. if that is the perfered work around?

I guess I rarely actually used the link to the console statement and didn't even notice it was gone :) I personally use the Chrome debugger most of the time.

if there is a way i can use the breadcrumbs or an equivilant api in a development setting

You can use Raven.captureBreadcrumb today if you just want to set a breadcrumb. The API isn't really fleshed out though yet. This is still a new feature and we're still trying to work out some bits.

If this is not a serious blocker, I'd like to keep this issue open for a bit and see if we get any more feedback.

I think this is a major issue, especially that its not documented anywhere and can't be disabled.
There might be tons of console.log that we don't want sent to Sentry.

Its up to the developer to choose what to send and when

One more thing that I did not mention, there some JS frameworks like Ember.js, tend to strip out console() methods from production builds. I am not sure if that would be a problem for sentry per se, but it does kinda lessen the benefits of the feature (at least for production code). Just food for consideration.

above comment appears to be incorrect, sorry.

@benvinegar I appreciate you are willing to keep the ticket open, it might be worth investigating some more:)

@benvinegar this issue is not a serious blocker at all.

Here is my current solution. I realized I can just _not_ initialize the raven.js client when in development mode... raven/sentry reporting, is only really useful to most people (i imagine) in production apps anyway.

That being said. there might still be some use in introducing maybe a developmentMode config flag, which would allow messages and errors to pass through to the dev console (aka disabling some of the "global" handling).. while keeping the raven.js client quiet in the background, so we could still manually send error reports, by explicitly triggering the raven apis, if we wish.

Let me know how you feel about that. Otherwise I would not worry too much about it, as this issue was mostly caused by my inexperience with raven and how/when to be using it.

There might be tons of console.log that we don't want sent to Sentry.

Real talk – do you actually want to disable this? I'm not trying to sound passive aggressive here, I just want to know if this is a serious problem right now and you want to disable it.

I think this is a major issue, especially that its not documented anywhere and

It is documented in the Raven.js changelog. We also published a blog post announcing breadcrumbs that mentions that console.log statements are now logged, and this post was broadcasted in-app to all hosted Sentry users. I'm sorry that we didn't manage to reach you, but I think a genuine effort was made to communicate this.

Note also that this is why Raven.js 3.0.x was a major version bump, because it introduced potentially breaking changes. I hope that people are reviewing the changelog before upgrading to a major version.

... can't be disabled.

In the meantime, you can still run Raven 2.x.

@benvinegar I appreciate you are willing to keep the ticket open, it might be worth investigating some more:)

I want to collect more feedback before rushing into a solution. Especially since 3.0.x has been live for a couple weeks and most of the feedback we have gotten has been positive.

@benvinegar this issue is not a serious blocker at all.

Yeah, I had a feeling you were curious more than anything.

That being said. there might still be some use in introducing maybe a developmentMode config flag, which would allow messages and errors to pass through to the dev console (aka disabling some of the "global" handling).. while keeping the raven.js client quiet in the background, so we could still manually send error reports, by explicitly triggering the raven apis, if we wish.

Yeah, the problem with that is that there is an argument for wanting console statements in production for debugging too. I'd rather just make it configurable. And, we will. I just want to get more feedback / measure impact first.

Anwyays, appreciate both your comments here, really.

@benvinegar: 👍 for config option — ideally allowing to filter out unwanted entries by hand (or rather function)

This keeps coming up on the support tracker as well. I think we should add a method to disable it.

Please make the breadcrumbs feature optional, wrapping console methods is risky and prone to conflicts with many other libs and 3rd party scripts that also try to.

As of 3.5.0 you can disable automatic collection of console breadcrumbs:

Raven.config('your dsn', {
  autoBreadcrumbs: {
    console: false
  }
});

Or you can disable automatic breadcrumb collection entirely:

Raven.config('your dsn', { autoBreadcrumbs: false });

More on this in docs.

autoBreadcrumbs is not there in typescript declaration file. Is it intentional?

https://github.com/getsentry/raven-js/blob/master/typescript/raven.d.ts

We've been struggling with TypeScript declarations lately. Submissions welcome.