Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allowing `debugger` statements during development #260

Closed
jameslnewell opened this issue Sep 16, 2015 · 9 comments

Comments

@jameslnewell
Copy link

commented Sep 16, 2015

I know standard is all about no-configuration but could there be a --dev or --debug flag that allows the debugger statement? It's really helpful during debugging - manually having to find and set breakpoints sucks!

I'm also curious as to why no-debugger is enabled but no-console isn't?

@feross

This comment has been minimized.

Copy link
Member

commented Sep 21, 2015

Thanks for the thoughtful issue. console.log statements won't break your app in production, but a stray debugger left in your code will certainly do that. That's the key difference.

If standard failures are preventing you from running your app, consider moving it from your regular tests to a separate lint task so you can test your app even with code style failures.

We haven't added any flags that change rules yet and I don't think it's worth the added complexity just to support this use case. Sorry.

@feross feross closed this Sep 21, 2015

@jameslnewell

This comment has been minimized.

Copy link
Author

commented Sep 21, 2015

I like fast feed feedback with linting as part of the default/watch tasks. Thanks for the explanation though. 😄

@rstacruz

This comment has been minimized.

Copy link
Member

commented Sep 21, 2015

Also, there's legitimate uses of console.log when writing CLI apps

@feross

This comment has been minimized.

Copy link
Member

commented Sep 21, 2015

@jameslnewell No problem :) FWIW, the eslint page for this rule says this:

The debugger statement is used to tell the executing JavaScript environment to stop execution and start up a debugger at the current point in the code. This has fallen out of favor as a good practice with the advent of modern debugging and development tools. Production code should definitely not contain debugger, as it will cause the browser to stop executing code and open an appropriate debugger.

The dev tools are a great way to set breakpoints!

@feross

This comment has been minimized.

Copy link
Member

commented Sep 21, 2015

@rstacruz That's another good point!

@jameslnewell

This comment has been minimized.

Copy link
Author

commented Sep 22, 2015

Yeah good point about cli apps.

I don't understand why debugger statements would have fallen out of favor unless people let them slip into prod code??? Its a lot easier to insert a debugger statement where I'm editing code in an IDE and reload the page than it is to edit code, trawl the source code panel in a browser, set a breakpoint and reload the page - usually for multiple breakpoints. Especially when breakpoint line numbers may change between builds and I might have to set the breakpoints all over again.

@rstacruz

This comment has been minimized.

Copy link
Member

commented Sep 22, 2015

You can use this:

debugger // eslint-disable-line

or:

/* eslint-disable no-debugger */
@jameslnewell

This comment has been minimized.

Copy link
Author

commented Sep 22, 2015

ty good point

@m5rk

This comment has been minimized.

Copy link

commented Jan 5, 2018

@rstacruz Your post from over 2 years ago is my goto:

I add debugger in some eslint-monitored code that disallows it. I see the error. I can't remember how to allow it. I google, "eslint debugger allow", I find this issue and your post, and copy what you provided. Thanks!

@feross feross added enhancement and removed enhancement labels May 10, 2018

@lock lock bot locked as resolved and limited conversation to collaborators Aug 8, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
5 participants
You can’t perform that action at this time.