Tslint: TSLint is completely ignoring a directory

[dwjft]

Bug Report

• __TSLint version__: 5.11.0
• __TypeScript version__: 3.1.4
• __Running TSLint via__: (pick one) CLI

TypeScript code being linted

entire directory

with tslint.json configuration:

{
  "extends": ["tslint:latest", "tslint-config-airbnb"],
  "rules": {
    "no-submodule-imports": false,
    "no-implicit-dependencies": false,
    "interface-over-type-literal": false,
    "max-line-length": false,
    "object-literal-sort-keys": false,
    "ordered-imports": false,
    "import-name": false,
    "align": false,
    "mocha-avoid-only": true,
    "trailing-comma": [
      true,
      {
        "esSpecCompliant": true
      }
    ]
  }
}

tsconfig.json

  "include": [
    "test/**/*"
  ],

Actual behavior

tslint -p tsconfig.json -t stylish
> no output

Expected behavior

tslint -p tsconfig.json -t stylish
> lint error

For some reason, I can't get tslint to lint over my test directory. I can place any other directory structure in the include in my tsconfig and it'll work fine. I've even tried without a config and tslint 'test/**/*' which would work fine if it was src/**/*.

[JoshuaKGoldberg]

@dwjft that's unfortunate! Sorry to hear it's not linting your test files. A couple clarifying questions:

• What are the contents of your tsconfig.json?
• What's the rough file structure of your test directory? _(is it a bunch of files under ./test/, or nested folders within that, or...?)_

If this is an open source project, that'd be great - could you post a link here?

Also, to help see where in the tslint command things are going wrong, can you add these logs to the node_modules/lib/linter.js file under the tslint package _(you might have to use which/where to find its location)_ and post the result here?

• Last line of the file: console.log("Hello, world!"); _(just to make sure it's being run)_
• Line 95, first line of Linter.prototype.lint: console.log({ fileName });

[dwjft]

A verbose option so we don't have to edit source code would be great! I spent a long time looking for that. [edited to add: a long time looking for a verbose option, not the file to edit!]

Interestingly, it seems the linter is finding the files but isn't actually pulling up any lint errors in those files.

The Hello, world! is being printed, and the file names are also being printed.

I removed the src/ directory from my include path but the linter is still picking up files there. Is that because the linter follows file imports and scans them also?

{ "fileName": "test/helpers/server.ts" }

It found this and multiple other test files in there.

Rough layout for test:

test
- files
-- *.txt
- helpers
-- *.ts

tsconfig content:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@test/*": ["./test/*"],
      "*": ["./src/*"]
    },
    "types": [
      "node",
      "mocha",
      "should"
    ],
    "typeRoots": [
      "./node_modules/@types",
      "./types"
    ],
    "lib": ["es2018"],
    "target": "es2018",
    "module": "commonjs",
    "noUnusedLocals": true,
    "inlineSources": true,
    "inlineSourceMap": true,
    "outDir": "build"
  },
  "include": [
    "src/**/*",
    "test/**/*"
  ],
  "exclude": [
    "build",
    "dist",
    "node_modules",
    "types",
    "config",
    "src/_scripts"
  ]
}

[dwjft]

"trailing-comma": [
      true,
      {
        "esSpecCompliant": true
      }
    ]

It appears to be this rule causing an issue.

Even with just trailing-comma: true it does not pick up on these errors.

It seems that this rule has to be completely removed from tslint.json for it to work.

---

Looks like this bug is actually around that rule, then. Unfortunately my codebase is now stuck in limbo because I need the esSpecCompliant option to handle the conflicting ts and tslint rule errors.

[dwjft]

Okay I appear to have resolved the issue with the following rule:

"trailing-comma": [true, {
      "multiline": "always",
      "singleline": "never",
      "esSpecCompliant": true
    }]

[JoshuaKGoldberg]

verbose option

Agreed, and great idea. --verbose? --debug? --trace? Would you like to file a separate issue with your thoughts on what you'd like to see in it? I can if not, but it'd be nice to fork into a separate discussion starting with what you're looking for.

resolved the issue with the following rule

Well that's bizarre and unprecedented. Rule are run inside a try/catch so if it was throwing errors, you'd be getting nice stack traces... Any chance you could post & link your project here?

[dwjft]

I'll let you do the fork to kickstart that discussion if you're interested. I think the basic first version should just be those 2 commands you gave me to edit in to the file. --verbose just logging out to console those things would help immensely.

I can't post / link the project since it is private; but I'll go ahead and close this comment and reply to it after I re-produce it in a clean environment.

Thanks for your timely help / support.

[anasofiapaixao]

For anyone arriving here via google like I did, I was having a very similar issue. With no excludes configured, running
tslint ./src/**/*.ts
worked, while running
tslint ./test/**/*.ts
did not. I managed in my case to narrow down the problem to arbitrary depth wildcards, **, working like singular wildcards; the pattern was interpreted as ./folder/*/*.ts and because the files in my src folder just happened to be at the right depth, the problem didn't manifest.

The workaround was quoting the paths like this answer explains. It seems that when the path is passed with quotes, it is handled with node-glob rather that by the shell (I was using terminator; ** wildcards work on bash) and in this case it did the trick. So I just changed it to
tslint './test/**/*.ts'
with quotes.