bitHound Blog

Configuring bitHound 101

bitHound analyzes your code and dependencies with defaults we feel make sense for most projects we encounter; however, at times project owners will want to tweak analysis on bitHound further to better match their style and requirements. Most of this customization happens in a .bithoundrc file that you would commit to your repository's root. Other configuration happens in the app itself. We'll outline which is which.

Code analysis configuration

Dependencies analysis configuration



Configuring Code Analysis

Ignoring files and folders

bitHound starts with a standard set of files and folders that it will ignore in your project, such as those in vendor folders and minified files. If you would like to customize this list, you can modify the default .bithoundrc file. If you like the defaults, but want to make additions, remember to keep the existing values in the default .bithoundrc file so you keep the existing rules as well as your new ones.

 "ignore": [
    "**/deps/**",
    "**/node_modules/**",
    "**/thirdparty/**",
    "**/third_party/**"
  ]

See a gist of the default .bithoundrc ignores.

Specifying your test files and folders

bitHound treats test files a bit different than your other project files. File length, for example, is not as critical as a metric, and are scored accordingly. bitHound defaults to looking in test and spec folders to find your test files. If you keep them in a different place, you can specify that in .bithoundrc.

"test": [
    "**/test/**",
    "**/tests/**",
    "**/spec/**",
    "**/specs/**"
  ]

See a gist of the default .bithoundrc test file locations.

Lint Engine Configuration

There are some cases where we are unable to detect which platform you want to use or you want to be explicit with what you use. You can now configure the linting engine in your .bithoundrc:

"critics": {
  "lint": {"engine": "standard"}
}

The supported values at this time are:

  • jshint
  • eslint
  • tslint
  • standard
  • semistandard (because some of us like semicolons)
  • none (in case you want to disable lint)

Long File Customization

You can now set the max limit for file length in your .bithoundrc with:

"critics": {
  "wc": { "limit": 5000 }
}

Custom JSHint or ESLint rules

If you are already using JSHint or ESLint and have setup your project's defaults, bitHound will respect those values and use that to provide analysis. If you do not have either configured, bitHound uses default values.


Configuring Dependencies Analysis

Flagging disallowed licenses for modules

(npm + Bower) bitHound allows you to specify what licenses you are comfortable allowing in your projects. Any modules that don't have licenses that match this will be marked as "Disallowed". To set this up, simply go to your project's settings and enter your vetted licenses.

Licenses in project settings

Learn more about configuring these licenses for your projects.

Ignoring modules marked as Unused

(npm only) bitHound will detect whether a module is being used in your project or not, but at times there may be some uses that we don't detect (e.g. when they are used in tests or inline script tags). If a module is being marked as unused, but you know that to be incorrect, you can have bitHound skip this analysis. Add an unused-ignore section to your dependencies section of your .bithoundrc:

  "dependencies": {
    "unused-ignores": [
      "grunt-*",
      "bower",
      "eslint"
    ]
  }

See here for a full example of a .bithoundrc ignoring unused modules.
Learn more about ignoring modules being marked as Unused in bitHound.

Muting modules

(npm only) At times you may want to mute a dependency as you've already vetted its issues and feel comfortable with how you are using it. In these cases, you can specify muted modules in your .bithoundrc config file. As always, we encourage you to take action, which can sometimes mean opening issues or pull requests to the package itself. Learn more about muting modules.

  "dependencies": {
    "mute": [
      "foo",
      "bar"
    ]
  }

See here for a full example of a .bithoundrc with muted modules
Learn more about muting vetted npm packages.

Custom package.json location

For those who keep a package.json file somewhere other than the root directory of the project, you can configure your .bithoundrc file to have bitHound look for that file in the specified location.

"packageJsonLocation": "foo/package.json"

See here for a full example of a .bithoundrc specifying a custom package.json location.
Learn more about specifying a default package.json location in bitHound.


Have questions? Let us know!

bitHound identifies risks and priorities in your Node.js projects.