Trying to create simple project to build and test custom rules

[abierbaum]

Bug Report

• TSLint version: 3.8.1
• TypeScript version: 1.8.10
• Running TSLint via: CLI

I am interested in creating some custom rules.

I started with the documentation here:

• http://palantir.github.io/tslint/develop/custom-rules/
• http://palantir.github.io/tslint/develop/testing-rules/

and decided to try to make a basic project with one simple rule and see if I could use the test framework created in #620. It all looks great, but I can't see to get it working.

I pushed a project up that shows what I am trying to do: https://github.com/abierbaum/tslint_custom_rule_seed

For now I kept it very very simple. I have:

• A rules directory with one rule (copied from the documentation)
• A tests/rules directory with one test (copied from the documentation)
• A shell script that calls tsc and tslint in the way I think should build and test the rule

#!/bin/bash
set -v

# Compile all rules
./node_modules/.bin/tsc

# Now run the tests
./node_modules/.bin/tslint --rules-dir ./rules --test test/rules/no-imports/default

Unfortunately it is not working. When I run it I get:

/home/allenb/Source/tslint_custom_rule_seed/node_modules/tslint/lib/ruleLoader.js:29
        throw new Error(errorMessage);
        ^

Error: Could not find the following rules specified in the configuration:
no-imports
    at Object.loadRules (/home/allenb/Source/tslint_custom_rule_seed/node_modules/tslint/lib/ruleLoader.js:29:15)
    at Linter.lint (/home/allenb/Source/tslint_custom_rule_seed/node_modules/tslint/lib/tslint.js:26:44)
    at Object.runTest (/home/allenb/Source/tslint_custom_rule_seed/node_modules/tslint/lib/test.js:27:39)
    at Object.<anonymous> (/home/allenb/Source/tslint_custom_rule_seed/node_modules/tslint/lib/tslint-cli.js:90:26)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)

Does anyone see what I am doing wrong in here? The new testing system looks great but I can't seem to get it to work.

@jkillian Am I using the testing system in the way you expected for this type of usage? (I think I followed what was described in #620 and #941

[jkillian]

Thanks for the detailed report @abierbaum!

This is a bug, it turns out that the TSLint CLI doesn't pay attention to the --rules-dir flag when you use the --test command. To add insult to injury, it doesn't even load the tslint.json file it is processing quite right either. However, there's still a fix you can make to get it working with the current version of TSLint. Try changing your tslint.json file to this:

{
  "rulesDirectory": "./rules",
  "rules": {
    "no-imports": true
  }
}

In the future, the command-line flag should work. Or, in the future, the path in the tslint.json file will be relative to the location of the file instead of relative to the current working directory.

[abierbaum]

@jkillian Thanks for the quick feedback. I tried that and it worked. Just pushed the change back up to https://github.com/abierbaum/tslint_custom_rule_seed

A couple of followup questions:

1. Is this the way you anticipated people would create/test custom rules outside of tslint using the testing framework? (any suggestions you have would be appreciated, just trying to use best practices here whatever they may be)
2. Is there any way to have tslint --test scan tests across a directory of tests. That would be very handy for building and testing a set of rules.

Thanks again.

[jkillian]

1. Your usage looks great to me! Sorry about the bugs, I see now that the tests I worte to test the --test flag only tested it using built-in rules, which was a little bit silly...

2. This is the short bit of code that TSLint uses to run tests on all of its rules, I imagine you could do something similar in your case. On the other hand, you could also write a shell script to do the same using the tslint --test command, to each his own here.

[abierbaum]

@jkillian Thanks for the great pointers. I took what you suggested and built up a pretty nice new name rule (ext-variable-name) See: https://github.com/vrsource/vrsource-tslint-rules

It allows very fine grained variable name checks based upon the type of the variable (class, interface, parameter, property, method, function, etc) along with the way it is modified/used (static, public, private, protected, local, const, etc) and can then be checked against pascal, camel, snake, upper, and regex values along with allowing leading/trailing underscore. It allows from some pretty sweet configurations to cover various coding styles. (we have one that is pretty hairy which is why I worked on it).

The new test framework worked great. I can't imagine trying to test this rule without it. :)

[jkillian]

@abierbaum Just merged a commit that should fix the behavior of the --test command. I expect to do a release tomorrow that'll have this change. It'll probably break your current usage of the --test command though, because:

the path in the tslint.json file will be relative to the location of the tslint.json file instead of relative to the current working directory.