tslint-ban-snippets readme

A custom tslint rule to ban configurable lists of code snippets.

examples: "return void reject", "it.only", "debugger".

status - stable

tslint-ban-snippets is stable and in use every day in CI builds and on dev boxes (Linux, Mac, Windows) for at least one major product.

dependencies

No special dependencies - just TypeScript and of course tslint.

custom tslint rule

The custom rule tsl-ban-snippets can be configured with small snippets of code that should NOT be used by developers.

If tslint finds the snippets of code, it will raise an error for that line of code.

In this way, a code base can be kept clean of unwanted coding practices.

note: the rule name

The rule name is tsl-ban-snippets to avoid using the prefix tslint- which was found to be problematic when other tslint libraries are in use.

note: comparison to the standard ban rule

There is standard tslint rule named ban. However its scope is quite limited - the tsl-ban-snippets rule applies to any statement in a TypeScript file, and so can be configured to detect most unwanted code snippets.

usage

1 Install via npm (or yarn) into your TypeScript project

npm install tslint-ban-snippets

2 Configure tslint to pick up the custom rule

Edit your tslint.json to have an entry "rulesDirectory" that points to tslint-ban-snippets.

Normally this would be like:

{
    "rulesDirectory": "node_modules/tslint-ban-snippets/dist/lib",
    "rules": {
        // tslint rules here...
    }
}

3 Configure the custom rule tsl-ban-snippets

Now you can configure the custom rule, to ban whatever code snippets you do NOT want developers to use.

examples

Example of how to ban the use of "return void":

    "rules": {
        // other rules here...
        "tsl-ban-snippets": [
            true,
            {
                "banned": [
                    {
                        "snippets": ["return void"]
                    }
                ]
            }
        ]
    }

Here is another example, with more options:

    "rules": {
        // other rules here...
        "tsl-ban-snippets": [
            true,
            {
                "banned": [
                    {
                        "snippets": ["return void"],
                        "message": "Please do not return void - instead place the return statement on the following line.",
                        "includePaths": [".ts", ".tsx"],
                        "excludePaths": ["itest"]
                    }
                ]
            }
        ]
    }

For more examples of how to configure, please see tslint.json.

For working examples, please see the unit tests.

sites

developing code in this repo

dependencies

We use semantic-release to manage versioning and the build process.

npm install -g semantic-release-cli

use a feature branch

Any pushes to master will try to publish to npm (if travis build succeeds). So it's best to first develop on a feature branch - named like feature/my-feature, and then when it has a green build, merge it master.

This project uses semantic release, so when committing its best to use this script:

./commit.sh

merging to master

merging a feature branch into master: (after the bulid is green!)

git checkout master
git fetch
git pull
git merge feature/my-feature
git push

releasing (from master branch)

To release, simply push to github. This will automatically run builds, generate release notes on github, and release to npm!

git push

origin

This project is based on the excellent seeder project typescript-library-starter

The project was started to avoid having to repeatedly fix similar coding issues in large TypeScript code bases.

ORIGINAL readme

see here

authors

Original work by Sean Ryan - mr.sean.ryan(at gmail.com)

licence = MIT

This project is licensed under the MIT License - see the LICENSE file for details