What is the difference between `extends` and `rulesDirectory` in TSLint

17
votes

The TSLint.json config file (https://github.com/palantir/tslint) supports extends and a rulesDirectory array like so

{
  "extends": [
    "tslint-microsoft-contrib",
    "tslint-config-security"
  ],
  "rulesDirectory": [
    "node_modules/tslint-eslint-rules/dist/rules",
    "node_modules/tslint-microsoft-contrib",
    "node_modules/tslint-config-security"
  ]
}

The docs seem slightly open to interpretation for new users unfamiliar to the tool.

I would appreciate if anyone could clarify a few points on the behaviour of extends and rulesDirectory in relation to use in the VS Code editor and tslinting in general.

  1. Does extends only provide a default configuration (if provided by package)?

  2. and is this therefore different to rulesDirectory?

    • Does rulesDirectory only provide rules for you to specifically opt-in(and is required if specifying rules in the root tslint.json)?

    • Should I still specify the tslint packages in both extends and rulesDirectory?

  3. Assuming extends provides defaults from another tslint config file, would I be able to specify the rulesDirectory and add a rule to override a specific flag?

Concerned because only some of the rules show up in IntelliSense autocompletion and just a few behaviours that I would appreciate more clarity for.

3
typescripteslintlinttslint
^V Please comment why you have down-voted so I can improve the question to your liking. - mittens pair
The extends configuration option extends the tslint.json configuration in the named package and makes available the rules in the named package. Whether or not the package's tslint.json enables any of its rules be default is a decision for the package author. I have several TSLint packages that provide default configurations that have no rules enabled, so using extend simply makes the packages' rules available in a more concise manner than specifying paths to the packages' rules directories. - cartant
Thanks @cartant for the comprehensive answer! So I can safely remove the rulesDirectory? Also, Does your IDE autocomplete work for your packages' rules when adding them in? I see your work on TSLinting RxJS. I wish I had noticed that earlier when I was trying to sort out different RxJS versions while learning! I would happily accept your answer for this question - mittens pair
No. I use VS Code and, AFAICT, it only autocompletes the built-in rules. It's not something that I've looked into and it's not something I've ever relied upon. The rules in my packages include the required metadata - it's in the rules' code - but what's behind the autocompletion and whether or not it requires something in addition to the metadata, I have no idea. - cartant
Ok. Thanks for your assistance. I really appreciate it. I'll just stick to specifying the rules for now 😊. - mittens pair

3 Answers

8
votes

What is the difference between extends and rulesDirectory in TSLint

They are very different.

  • extends allows you to apply an existing tslint config and then extend it
  • rulesDirectory simply allows you to add directories for custom rules.
2
votes

?Answer taken from tslint configuration docs as of 6 April 2018:

  • extends?: string | string[]: The name of a built-in configuration preset (see built-in presets below), or a path or array of paths to other configuration files which are extended by this configuration. This value is handled using node module resolution semantics. For example, a value of "tslint-config" would tell TSLint to try and load the main file of a module named "tslint-config" as a configuration file. Specific files inside node modules can also be specified, eg. "tslint-config/path/to/submodule". Relative paths to JSON files or JS modules are also supported, e.g. "./tslint-config".
  • rulesDirectory?: string | string[]: A path to a directory or an array of paths to directories of [custom rules][2]. These values are handled using node module resolution semantics, if an index.js is placed in your rules directory. We fallback to use relative or absolute paths, if the module can't be resolved. If you want to avoid module resolution you can directly use a relative or absolute path (e.g. with ./).

Any rules specified in this rules block will override those configured in any base configuration being extended.

0
votes

Take a look at docs.

Seems the main difference is:

  • "extends" uses sets of build-in rules

  • "rulesDirectory" uses custom (your own, not build-in) rules