Use strings to denote severity in rules

Author: robertrossmann

coding-styles/fixable.js

@@ -14,51 +14,51 @@ module.exports = {
   rules: {
     // Validate closing bracket location in JSX
     // This rule checks all JSX multiline elements and verifies the location of the closing bracket.
-    'react/jsx-closing-bracket-location': [1, 'line-aligned'],
+    'react/jsx-closing-bracket-location': ['warn', 'line-aligned'],
 
     // Disallow spaces inside of curly braces in JSX attributes
-    'react/jsx-curly-spacing': [1, 'never', {
+    'react/jsx-curly-spacing': ['warn', 'never', {
       allowMultiline: true,
     }],
 
     // Enforce or disallow spaces around equal signs in JSX attributes
     // This rule will enforce consistency of spacing around equal signs in JSX attributes, by
     // requiring or one or more spaces before and after =.
-    'react/jsx-equals-spacing': [1, 'never'],
+    'react/jsx-equals-spacing': ['warn', 'never'],
 
     // Configure the position of the first property
-    'react/jsx-first-prop-new-line': [1, 'multiline'],
+    'react/jsx-first-prop-new-line': ['warn', 'multiline'],
 
     // Validate JSX indentation
-    'react/jsx-indent': [1, 2],
+    'react/jsx-indent': ['warn', 2],
 
     // Validate props indentation in JSX
-    'react/jsx-indent-props': [1, 2],
+    'react/jsx-indent-props': ['warn', 2],
 
     // Enforce PascalCase for user-defined JSX components
     // Enforces coding style that user-defined JSX components are defined and referenced in
     // PascalCase.
-    'react/jsx-pascal-case': [1, {
+    'react/jsx-pascal-case': ['warn', {
       allowAllCaps: true,
       ignore: [],
     }],
 
     // Validate spacing before closing bracket in JSX
     // This rule checks if there is one or more spaces before the closing bracket of self-closing
     // JSX elements.
-    'react/jsx-space-before-closing': [1, 'always'],
+    'react/jsx-space-before-closing': ['warn', 'always'],
 
     // Validate whitespace in and around the JSX opening and closing brackets
     // This rule checks the whitespace inside and surrounding the JSX syntactic elements.
-    'react/jsx-tag-spacing': 1,
+    'react/jsx-tag-spacing': 'warn',
 
     // Prevent extra closing tags for components without children
-    'react/self-closing-comp': 1,
+    'react/self-closing-comp': 'warn',
 
     // Enforce component methods order
     // When creating React components it is more convenient to always follow the same organisation
     // for methods order to helps you to easily find lifecyle methods, event handlers, etc.
-    'react/sort-comp': [1, {
+    'react/sort-comp': ['warn', {
       order: [
         'static-methods',
         'lifecycle',

coding-styles/react.js

@@ -18,37 +18,37 @@ module.exports = {
     // This rule enforces consistent use of trailing commas in object and array literals
     // Allow trailing commas for func parameters, array and object literals spread across
     // multiple lines
-    'comma-dangle': [1, 'always-multiline'],
+    'comma-dangle': ['warn', 'always-multiline'],
 
     // Require Camelcase
     // This rule looks for any underscores (_) located within the source code. It ignores leading
     // and trailing underscores and only checks those in the middle of a variable name. If ESLint
     // decides that the variable is a constant (all uppercase), then no warning will be thrown.
-    camelcase: [1, {
+    camelcase: ['warn', {
       properties: 'always',
     }],
 
     // Require Consistent This
     // This rule designates a variable as the chosen alias for `this`.
-    'consistent-this': [1, 'self'],
+    'consistent-this': ['warn', 'self'],
 
     // Enforce Function Style
     // Due to these different behaviors, it is common to have guidelines as to which style of
     // function should be used. There is really no correct or incorrect choice here, it is just a
     // preference. A good reason to use function declarations is that the function names then appear
     // in stack traces which help during debugging.
     // Allow arrow functions to be saved into variables
-    'func-style': [1, 'declaration', {
+    'func-style': ['warn', 'declaration', {
       allowArrowFunctions: true,
     }],
 
     // Require function names to match the name of the variable to which they are assigned
-    'func-name-matching': 1,
+    'func-name-matching': 'warn',
 
     // Limit minimum and maximum length for identifiers
     // This rule is aimed at increasing code readability and maintainability by enforcing an
     // identifier length convention.
-    'id-length': [1, {
+    'id-length': ['warn', {
       min: 2,
       max: 25,
       exceptions: [
@@ -61,95 +61,95 @@ module.exports = {
     // Very long lines of code in any language can be difficult to read. In order to aid in
     // readability and maintainability many coders have developed a convention to limit lines of
     // code to a certain number of characters.
-    'max-len': [1, 100, 2],
+    'max-len': ['warn', 100, 2],
 
     // Limit Maximum Number of Parameters
     // Functions that take numerous parameters can be difficult to read and write because it
     // requires the memorization of what each parameter is, its type, and the order they should
     // appear in.
-    'max-params': [1, 4],
+    'max-params': ['warn', 4],
 
     // Set Maximum Depth of Nested Callbacks
     // This rule is aimed at increasing code clarity by discouraging deeply nesting callbacks.
-    'max-nested-callbacks': [1, 4],
+    'max-nested-callbacks': ['warn', 4],
 
     // Specify the Maximum Number of Statements Allowed per Line
     // A line of code containing too many statements can be difficult to read. Code is generally
     // read from the top down, especially when scanning, so limiting the number of statements
     // allowed on a single line can be very beneficial for readability and maintainability.
-    'max-statements-per-line': 1,
+    'max-statements-per-line': 'warn',
 
     // Require Constructors to Use Initial Caps
     // This rule is aimed at helping to distinguish regular functions from constructor functions. As
     // such, it warns whenever it sees new followed by an identifier that isn't capitalized or
     // whenever it sees capitalized function called directly without new operator.
-    'new-cap': [1, {
+    'new-cap': ['warn', {
       newIsCap: true,
       capIsNew: true,
     }],
 
     // Newline Per Chained Method Call
     // This rule checks and reports the chained calls if there are no new lines after each call or
     // deep member access.
-    'newline-per-chained-call': [1, {
+    'newline-per-chained-call': ['warn', {
       ignoreChainWithDepth: 3,
     }],
 
     // Disallow duplicate exports/imports
     // An ES6/ES2015 import can be spread over multiple lines, but this takes up unneeded
     // whitespace. This rules validates that all imports from a single module exists in a single
     // import statement.
-    'no-duplicate-imports': [1, {
+    'no-duplicate-imports': ['warn', {
       includeExports: true,
     }],
 
     // Disallows comments after code
     // This rule will disallow comments on the same line as code.
-    'no-inline-comments': 1,
+    'no-inline-comments': 'warn',
 
     // Disallow mixes of different operators
     // Enclosing complex expressions by parentheses clarifies the developer’s intention, which makes
     // the code more readable. This rule warns when different operators are used consecutively
     // without parentheses in an expression.
-    'no-mixed-operators': 1,
+    'no-mixed-operators': 'warn',
 
     // Disallow mixed spaces and tabs for indentation
     // The no-mixed-spaces-and-tabs rule is aimed at flagging any lines of code that are indented
     // with a mixture of tabs and spaces.
-    'no-mixed-spaces-and-tabs': 1,
+    'no-mixed-spaces-and-tabs': 'warn',
 
     // Disallow tabs
     // Use of tabs is discouraged in favour of spaces because there is no "standard" width for a tab
     // character and many viewers/editors use their own tab width, which could cause code to be
     // misaligned and not formatted as intended/indented.
-    'no-tabs': 1,
+    'no-tabs': 'warn',
 
     // Disallow Nested Ternaries
     // The no-nested-ternary rule aims to increase the clarity and readability of code by
     // disallowing the use of nested ternary expressions.
-    'no-nested-ternary': 2,
+    'no-nested-ternary': 'error',
 
     // Disallow Dangling Underscores in Identifiers
-    'no-underscore-dangle': 1,
+    'no-underscore-dangle': 'warn',
 
     // Disallow Warning Comments
     // These comments are a warning signal, that there is something not production ready in your
     // code. Most likely you want to fix it or remove the comments before you roll out your code
     // with a good feeling.
-    'no-warning-comments': [1, {
+    'no-warning-comments': ['warn', {
       location: 'anywhere',
     }],
 
     // Require or Disallow One Variable Declaration per Scope
     // This rule is aimed at enforcing the use of one variable declaration per function (for var)
     // and multiple variable declaration per block (for let and const) scope.
-    'one-var': [1, {
+    'one-var': ['warn', {
       var: 'always',
       let: 'never',
       const: 'never',
     }],
 
     // Enforces having an empty line after the last top-level import statement or require call
-    'import/newline-after-import': 1,
+    'import/newline-after-import': 'warn',
   },
 }

coding-styles/recommended.js

@@ -20,43 +20,43 @@ module.exports = {
   rules: {
     // Enforce/Disallow Variable Initializations
     // You think you can get away with uninitialised variables? Hah! Forget it, dude!
-    'init-declarations': 1,
+    'init-declarations': 'warn',
 
     // Disallow Shadowing of Variables Inside of catch
     // No. Make up a new variable name.
-    'no-catch-shadow': 1,
+    'no-catch-shadow': 'warn',
 
     // Limit Maximum Number of Statements
     // Hit this limit? You are doing it wrong -> refactor!
-    'max-statements': [1, 15],
+    'max-statements': ['warn', 15],
 
     // Require newline before return statement
     // Make your returns obvious!
-    'newline-before-return': 1,
+    'newline-before-return': 'warn',
 
     // Disallow use of negated expressions in conditions
-    'no-negated-condition': 1,
+    'no-negated-condition': 'warn',
 
     // Import Sorting
     // Of course you should sort your imports! It makes your code look more like poetry!
-    'sort-imports': 1,
+    'sort-imports': 'warn',
 
     // Object key sorting
     // And of course you should sort your keys, who wants to look at such ugly, unsorted objects?
-    'sort-keys': 1,
+    'sort-keys': 'warn',
 
     // Variable Sorting
     // Sort all the things!
-    'sort-vars': 1,
+    'sort-vars': 'warn',
 
     // Disallow Magic Numbers
     // Nope. Define them as constants. Or something.
-    'no-magic-numbers': 2,
+    'no-magic-numbers': 'error',
 
     // Require Radix Parameter
-    radix: 1,
+    radix: 'warn',
 
     // Require Regex Literals to be Wrapped
-    'wrap-regex': 1,
+    'wrap-regex': 'warn',
   },
 }

coding-styles/torment.js

@@ -22,6 +22,6 @@ module.exports = {
     //
     // @see  https://www.npmjs.com/package/debug
     // @see  https://www.npmjs.com/package/bunyan
-    'no-console': 1,
+    'no-console': 'warn',
   },
 }

environments/nodejs/optional.js

@@ -17,16 +17,16 @@ module.exports = {
     // It's arguably harder to identify dependencies when they are deeply nested inside of functions
     // and other statements. Since require() does a synchronous load, it can cause performance
     // problems when used in other locations.
-    'global-require': 1,
+    'global-require': 'warn',
 
     // Disallow new require
     // This rule aims to eliminate use of the `new require` expression.
-    'no-new-require': 2,
+    'no-new-require': 'error',
 
     // Disallow string concatenation when using _dirname and _filename
     // This rule aims to prevent string concatenation of directory paths in Node.js to make sure
     // developers use a platform-independent way of creating paths (we feel you, Windows).
-    'no-path-concat': 2,
+    'no-path-concat': 'error',
 
     // Disallow process.env
     // This rule is aimed at discouraging use of process.env to avoid global dependencies throughout
@@ -36,17 +36,17 @@ module.exports = {
     // turned off for a particular file/folder where project configuration is gathered and stored in
     // custom configuration objects which you then use throughout your app, but the use of
     // process.env outside of preparing configuration data should be discouraged.
-    'no-process-env': 1,
+    'no-process-env': 'warn',
 
     // Disallow `process.exit()`
     // It's better to throw an error and allow the application to handle it appropriately. Unhandled
     // errors always exit the process, but contrary to `process.exit()` they also print a stack
     // trace.
-    'no-process-exit': 2,
+    'no-process-exit': 'error',
 
     // Disallow Synchronous Methods
     // This rule is aimed at preventing synchronous methods from being called in Node.js. It looks
     // specifically for the method suffix "Sync" (as is the convention with Node.js operations).
-    'no-sync': 1,
+    'no-sync': 'warn',
   },
 }

environments/nodejs/recommended.js

@@ -16,10 +16,10 @@ module.exports = {
     // Disallow Use of Alert
     // This rule is aimed at catching debugging code that should be removed and popup UI elements
     // that should be replaced with less obtrusive, custom UIs.
-    'no-alert': 1,
+    'no-alert': 'warn',
 
     // Enforce propTypes declarations alphabetical sorting
-    'react/sort-prop-types': [1, {
+    'react/sort-prop-types': ['warn', {
       ignoreCase: true,
       callbacksLast: false,
       requiredFirst: false,
@@ -30,6 +30,6 @@ module.exports = {
     // imported/exported. This allows people who want to use
     // babel-plugin-transform-react-remove-prop-types to remove propTypes from their components in
     // production builds, to do so safely
-    'react/forbid-foreign-prop-types': 1,
+    'react/forbid-foreign-prop-types': 'warn',
   },
 }