schemalint

Install schemalint as a development dependency using npm.

$ npm i -D schemalint

To run the linter, ensure you are in a directory containing a .schemalintrc.js configuration file, then execute npx schemalint.

$ npx schemalint

Schemalint allows you to define custom rules to enforce specific schema patterns. The example repository provides a template for custom rules located in the custom-rules directory.

Available Example Rules

• identifier-naming: Defined in identifierNaming.js.
• last-updated: Defined in lastUpdated.js.
• index.js: The entry point that exports the custom rules.

Implementation Guidance

To write your own rules, you should refer to the following technical specifications:

• Rule Object: Use the Rule type definition (found in src/Rule.ts) to structure your rule logic.
• Schema Object: The custom rule receives a Schema object (refer to the extract-pg-schema documentation) which contains the database structure information used for validation.

To test Schemalint with a sample database, you can use the provided example setup. This includes a Docker-based PostgreSQL sample database and a pre-configured schemalintrc.js file.

1. Start the sample database using Docker:

   npm run start-example-db

2. Install dependencies in the example folder:

   npm install

3. Run the linter using the local configuration:

   npm run lint:schema
   # or
   npx schemalint

Upon running, Schemalint will connect to the database, identify schema violations (e.g., prefer-text-to-varchar), and provide suggested SQL ALTER TABLE commands to fix the issues.

The mandatory-columns rule ensures that specific columns exist in a table. The configuration is an object where the key is the column name and the value is an object defining required properties.

You can use any property from the TableColumn object (e.g., isNullable, expandedType, ordinalPosition).

rules: {
  'mandatory-columns': ['error', {
    created_at: {
      expandedType: 'pg_catalog.timestamptz',
      isNullable: false,
    }
  }],
}

The require-primary-key rule identifies tables that lack a primary key. You can exclude specific tables or schemas from this check using the ignorePattern option.

rules: {
  'require-primary-key': ['error', {
    ignorePattern: 'information_schema.*'
  }],
}

The index-referencing-column rule enforces that an index is created on the referencing column of a foreign key constraint. This is a best practice to improve performance during DELETE or UPDATE operations on the referenced table.

rules: {
  'index-referencing-column': ['error'],
}

The name-casing rule ensures that tables, views, and columns follow a specific naming convention. The default is snake (e.g., member_profile).

You can configure the rule to use one of the following schemes:

• snake (default)
• dash (e.g., member-profile)
• camel (e.g., memberProfile)
• pascal (e.g., MemberProfile)

rules: {
  'name-casing': ['error', 'snake'],
},

You can define specific rules for individual schemas using the SchemaConfig type. When you provide rules within a schema configuration, they are merged with the global rules defined at the top level of the configuration. This allows you to enable or disable specific rules for certain parts of your database.

// Inside the schemas array in your config
{
  name: 'my_schema',
  rules: {
    'some-rule-name': ['error']
  }
}

The reference-actions rule enforces specific ON UPDATE and ON DELETE actions for foreign key constraints.

Supported actions:

• NO ACTION
• RESTRICT
• CASCADE
• SET NULL
• SET DEFAULT

If an action is not specified in the configuration, the rule allows any action for that specific direction (update or delete).

rules: {
  'reference-actions': ['error', {
    onUpdate: 'NO ACTION',
    onDelete: 'CASCADE',
  }],
}

The row-level-security rule checks if Row-Level Security (RLS) is enabled on tables. You can also use the enforced: true option to ensure that RLS is actively enforced.

rules: {
    'row-level-security': ['error', {enforced: true}],
}