global tslint throws error if extends config option references local package

[janslow]

Bug Report

• TSLint version: 3.8.1
• TypeScript version: 1.8.10
• Running TSLint via: (please choose one) CLI

TypeScript code being linted

tslint.json:

{
  "extends": "shared-tslint-config"
}

(where shared-tslint-config is a locally installed NPM package providing a tslint config)

Actual behavior

(when using a globally installed tslint)

$ tslint src/index.ts --config tslint.json

/usr/local/lib/node_modules/tslint/lib/configuration.js:122
            throw new Error(("Invalid \"extends\" configuration value - could not require \"" + relativeFilePath + "\". ") +
            ^

Error: Invalid "extends" configuration value - could not require "shared-tslint-config". Review the Node lookup algorithm (https://nodejs.org/api/modules.html#modules_all_together) for the approximate method TSLint uses to find the referenced configuration file.
    at resolveConfigurationPath (/usr/local/lib/node_modules/tslint/lib/configuration.js:122:19)
    at loadConfigurationFromPath (/usr/local/lib/node_modules/tslint/lib/configuration.js:101:38)
    at Object.findConfiguration (/usr/local/lib/node_modules/tslint/lib/configuration.js:45:12)
    at processFile (/usr/local/lib/node_modules/tslint/lib/tslint-cli.js:111:41)
    at Array.forEach (native)
    at Object.<anonymous> (/usr/local/lib/node_modules/tslint/lib/tslint-cli.js:128:41)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)

Expected behavior

tslint should resolve configuration file from locally installed package shared-tslint-config

[janslow]

I expect this is because, when run globally, require.resolve in resolveConfigurationPath() only has access to other global packages, not local ones.

[janslow]

There is a workaround of using a relative or absolute path to the config file to extend, instead of a module ID.

This obviously means you have to rely on the config file in the package not changing location in the package.

[jkillian]

This is known behavior and I had originally thought it was okay to have things work like this, but I'm glad you made this issue for discussion. This issue is pretty confusing behavior for end users, and changing it would be a big improvement.

Perhaps the best solution here is to use a 3rd-party require/resolve library that lets you "start" from a different starting location? So modules could be resolved relative to the location of the config file and also as they are now.

[janslow]

A package like resolve should do the job.

I'm happy to create a pull request, if you're happy with this as a solution.

[jkillian]

Sure, a PR would be great! Thanks @janslow