Seems like this config is being used out in the wild thanks to @trezy and his org trezy-studios.

Given this is that case we've begun getting feedback from others (Mainly @IanSSenne).

One point of contention has been the state of no-debugger. It's current config is:

    /**
     * disallow the use of debugger
     */
    'no-debugger': ['error'],

Under no circumstance do I think this rule should be turned off entirely. An unchecked debugger call in production can cause massive problems. Degrading to warn, however may have it's merits.

Below is just a collection of thoughts I've had on the topic

Good things about degrading to warn

• Become more environment agnostic. Not all environments are breakpoint friendly due to various reasons (thanks webpack and your often borked HMR source maps).
• warns can still break builds via strict linting when building on your CI

Bad things about degrading to warn

• warns CAN be missed by CI/CD configurations that don't opt into into fail-on-warning.
• warnings do not fully convey that it is essential to remove for production. To someone new to JS this can be confusing.

Problems with staying on error

• This compels developers who need to use debugger to add a eslint-disable or eslint-disable-line comment to get around it so it may be used temporarily. This in turn becomes a much larger problem on it's own because now it is undetectable by any form of CI lint task. We have had this very same problem in the past with console.log()

Other thoughts

• We cannot control the CI/CD configuration of other projects. This config is simply just not that opinionated on it's integration with your environment, and I think we have no intention on changing that.
• Rule configurations should reflect our stance on the feature the rule enforces. Since we haven't established this yet, we should decide if things projects can do to make their use of a feature acceptable should have any bearing upon that stance. This will be something to discuss with @xlexi

Open for any feedback!