/eslint-plugin-sql

SQL linting rules for ESLint.

Primary LanguageTypeScriptOtherNOASSERTION

eslint-plugin-sql

Travis build status NPM version Canonical Code Style Twitter Follow

SQL linting rules for ESLint.

In its current form, the plugin has been designed and tested to work with Postgres codebase.

Installation

  1. Install ESLint.
  2. Install eslint-plugin-sql plugin.
npm install eslint --save-dev
npm install eslint-plugin-sql --save-dev

Configuration

  1. Add plugins section and specify eslint-plugin-sql as a plugin.
  2. Enable rules.
{
  "plugins": [
    "sql"
  ],
  "rules": {
    "sql/format": [
      2,
      {
        "ignoreExpressions": false,
        "ignoreInline": true,
        "ignoreTagless": true
      }
    ],
    "sql/no-unsafe-query": [
      2,
      {
        "allowLiteral": false
      }
    ]
  }
}

Settings

placeholderRule

A regex used to ignore placeholders or other fragments of the query that'd make it invalid SQL query, e.g.

If you are using ? placeholders in your queries, you must ignore \? pattern as otherwise the string is not going to be recognized as a valid SQL query.

This configuration is relevant for sql/no-unsafe-query to match queries containing placeholders as well as for sql/format when used with {ignoreTagless: false} configuration.

Rules

format

The --fix option on the command line automatically fixes problems reported by this rule.

Matches queries in template literals. Warns when query formatting does not match the configured format (see Options).

This rule is used to format the queries using pg-formatter.

Options

The first option is an object with the following configuration.

configuration format default description
ignoreExpressions boolean false Does not format template literals that contain expressions.
ignoreInline boolean true Does not format queries that are written on a single line.
ignoreTagless boolean true Does not format queries that are written without using sql tag.
ignoreStartWithNewLine boolean true Does not remove \n at the beginning of queries.

The second option is an object with the pg-formatter configuration.

The following patterns are considered problems:

`SELECT 1`
// Options: [{"ignoreInline":false,"ignoreTagless":false}]
// Message: Format the query
// Fixed code: 
// `
// SELECT
//     1
// `

`SELECT 2`
// Options: [{"ignoreInline":false,"ignoreTagless":false},{"spaces":2}]
// Message: Format the query
// Fixed code: 
// `
// SELECT
//   2
// `

sql`SELECT 3`
// Options: [{"ignoreInline":false}]
// Message: Format the query
// Fixed code: 
// sql`
// SELECT
//     3
// `

`SELECT ${'foo'} FROM ${'bar'}`
// Options: [{"ignoreInline":false,"ignoreTagless":false}]
// Message: Format the query
// Fixed code: 
// `
// SELECT
//     ${'foo'}
// FROM
//     ${'bar'}
// `

The following patterns are not considered problems:

sql`SELECT 1`
// Options: [{"ignoreInline":true}]

`SELECT 2`
// Options: [{"ignoreTagless":true}]

`SELECT ${'foo'} FROM ${'bar'}`
// Options: [{"ignoreExpressions":true,"ignoreInline":false,"ignoreTagless":false}]

no-unsafe-query

Disallows use of SQL inside of template literals without the sql tag.

The sql tag can be anything, e.g.

Options

The first option is an object with the following configuration.

configuration format default description
allowLiteral boolean false Controls whether sql tag is required for template literals containing literal queries, i.e. template literals without expressions.

The following patterns are considered problems:

`SELECT 1`
// Message: Use "sql" tag

`SELECT ${'foo'}`
// Message: Use "sql" tag

foo`SELECT ${'bar'}`
// Message: Use "sql" tag

`SELECT ?`
// Message: Use "sql" tag

The following patterns are not considered problems:

`SELECT 1`
// Options: [{"allowLiteral":true}]

sql`SELECT 1`

sql`SELECT ${'foo'}`