Tslint: failing when running locally

[ksnyde]

Bug Report

• __TSLint version__: 4.0.1 (both globally and locally)
• __TypeScript version__: 2.0.10
• __Running TSLint via__: npm script

Actual Behaviour

My lint runner is an npm script which defined as this:

"scripts": {
  "clean": "rimraf lib",
  "lint": "tslint --force --format verbose \"src/**/*.ts\"",
  "build": "npm run clean && npm run lint && echo Using TypeScript && tsc --version && tsc --pretty",
  "test": "npm run build && mocha --compilers ts:ts-node/register --recursive test/**/*-spec.ts",
  "watch": "npm run build -- --watch",
  "watch:test": "npm run test -- --watch"
},

If I run tslint --force --format verbose "src/**/*.ts" from the terminal it works without error:

If, however, I run the npm lint script. It will run the locally install tslint and it fails with:

module.js:471
    throw err;
    ^

Error: Cannot find module './test/parse'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Volumes/PEGASUS/repos/mine/logger/serverless-event/node_modules/tslint/lib/test.js:27:13)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

This can be reproduced by just running the following at the terminal:

./node_modules/.bin/tslint --force --format verbose "src/**/*.ts"

Expected behavior

I would expect the local install of tslint to behave the same as the global install.

Final Note

In case it makes any difference, here are the deps in my project from package.json:

"dependencies": {
  "aws-sdk": "^2.7.5",
  "bluebird": "^3.4.6",
  "stacktrace-js": "^1.3.1"
},
"devDependencies": {
  "@types/bluebird": "^3.0.35",
  "@types/chai": "3.4.30",
  "@types/es6-promise": "^0.0.32",
  "@types/mocha": "2.2.29",
  "@types/node": "6.0.31",
  "@types/stacktrace-js": "^0.0.30",
  "chai": "^3.5.0",
  "mocha": "^3.0.1",
  "rimraf": "^2.5.4",
  "ts-node": "^1.2.2",
  "tslint": "4.0.1",
  "typescript": "2.0.10"
},

[nchen63]

I couldn't reproduce this issue using the command line example. Does ./node_modules/tslint/lib/test/parse.js exist in local?

[ksnyde]

I couldn't find it in either.

[ksnyde]

I have a new laptop as of today I'm going to try and recreate with the hope that I can't (but sadly with the believe that I will)

[nchen63]

here's what I see with a fresh tslint v4.0.1 install... do you have at least the other files?

[adidahiya]

why are files in lib/test loaded when running the CLI? ideally that should only happen when using the --test CLI option.

[jkillian]

lib/test actually corresponds to src/test which is various logic for running and parsing tests that is needed for the --test command in TSLint. Real tests just live in test and probably aren't included in the npm package

[adidahiya]

yes, I understand. my question still stands

[jkillian]

Whoops, misread that! Likely the CLI just imports things at the top of the
file for all of its commands, no matter the actual code path. On a phone
though, so don't have the code at hand

On Tue, Nov 22, 2016, 7:43 PM Adi Dahiya [email protected] wrote:

yes, I understand. my question still stands

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/palantir/tslint/issues/1770#issuecomment-262408748,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVdVxbvJDUIHCQwod33SsutPXzHAu_Zks5rA4whgaJpZM4K5a-G
.

[nchen63]

it's just part of the compilation process. When Node sees an import, it loads the file and compiles it.

[ksnyde]

Neither local or global have the test directory as pointed out by @JKillian. The test file that is failing is lib/test.js and it require's a "./test/parse" module which clearly does not exist.

If the test module is indeed used for linting then I can't understand why it doesn't fail all the time. If it's only used when run via npm run and with a local install, how would that get triggered conditionally?

Global install:

Local install:

[nchen63]

what is in your lib directory?

[ksnyde]

I have two cases where this is happening but here is one:

is this helpful? Also, for what its worth, I have a "test" directory which also has typescript in it which also fails in the same way.

[nchen63]

oh i mean in your tslint/lib directory?

[ksnyde]

Oh that makes more sense. 😊

[nchen63]

try:

• running npm pack tslint
• unpack the file
• verify that there is a package/lib/test/parse.js file.
• then run npm i tslint-4.0.2.tgz in an empty directory.
• verify that the directory contains node_modules/tslint/lib/test/parse.js

[ksnyde]

Yes I can confirm that it does have parse.js:

.

[ksnyde]

I have now installed 4.0.2 (versus 4.0.1) globally and it too has the parse.js, however when I run tslint src/*.ts from the root of my project (should be using global version of tslint) i get:

/usr/local/lib/node_modules/tslint/lib/tslint-cli.js:234
    throw error;
    ^

Error: Cannot find module './test/parse'
    at Function.Module._resolveFilename (module.js:469:15)
    at Function.Module._load (module.js:417:25)
    at Module.require (module.js:497:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/Volumes/PEGASUS/repos/mine/truecash-services/node_modules/tslint-eslint-rules/node_modules/tslint/lib/test.js:10:13)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)

In contrast, the local version (also 4.0.2 now) gives the same error message but rather than originating in the tslint-cli it just states:

module.js:471
    throw err;
    ^

[nchen63]

try npm i tslint-4.0.2.tgz -g

[ksnyde]

I installed with the above and now I do have the parse file:

but I still get the same error when running tslint src/*.ts from project root. I don't know if this sheds any light on things but when I try to install tslint without also installing typescript at the same time (even though typescript is installed both locally and globally to 2.0.10), I get:

[ksnyde]

May be a red herring but using the vs-code editor you can see below that there is a TSLint error:

Looking at this error you find:

[Info  - 11:42:45 AM] vscode-tslint: 'ENOENT: no such file or directory, open '/Volumes/PEGASUS/repos/mine/truecash-services/node_modules/tslint/lib/lint.js'' while validating: /Volumes/PEGASUS/repos/mine/truecash-services/src/db.ts stacktrace: Error: ENOENT: no such file or directory, open '/Volumes/PEGASUS/repos/mine/truecash-services/node_modules/tslint/lib/lint.js'
    at Error (native)
    at Object.fs.openSync (fs.js:640:18)
    at Object.module.(anonymous function) [as openSync] (ELECTRON_ASAR.js:168:20)
    at Object.fs.readFileSync (fs.js:508:33)
    at Object.fs.readFileSync (ELECTRON_ASAR.js:501:29)
    at Object.Module._extensions..js (module.js:564:20)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Module.require (module.js:483:17)

the source of this error appears to be a name change from lint.js to linter.js. In vs-code i had historically used the .vscode/settings.json to use the locally installed Typescript rather than the editor's built in but that's because they weren't running on the latest and I wanted to control this. I can get rid of this linting error in vs-code by reverting to the built-in linter. Either way, this has no direct impact on the error above but it is a disturbing change to the "contract" between editor and tool.

[ksnyde]

Hmmm. Actually using the "built-in" TSLint (in vs-code) doesn't give an error but it doesn't run TSLint either.

note it _is_ installed both globally and locally

[nchen63]

You need to upgrade vscode-tslint due to an API change

Try upgrading NPM. Since you're seeing something different when you install tslint using the tgz vs using npm i tslint, something is fundamentally off, and it doesn't sound like it's because of TSLint. Also the fact that you're seeing unmet peer dependency when it clearly is met indicates an NPM issue.

Your global library may be corrupted somehow. Try clearing it out, verifying everything is uninstalled by running tslint to make sure it doesn't work. Then reinstall everything

[ksnyde]

i removed all of my globally install npm files -- rm -rf /usr/local/lib/node_modules -- and started from scratch:

I then blow away my local environment too, and reinstall with yarn:

As you can see I am still getting the same error. 😢

Then I start up vs-code (1.7.2) and get the following in the "tslint window":

[Info - 5:41:06 PM] Failed to load the TSLint library.
To use TSLint in this workspace please install tslint using 'npm install tslint' or globally using 'npm install -g tslint'.
You need to reopen the workspace after installing tslint.

Very odd indeed. Even odder is when I go to a typescript file I see this in the gutter:

Version 2.1.1? I have version 2.0.10 installed globally and locally.

[ksnyde]

I have recreated this on my brand new macbook pro (which had nothing installed to start).

Note: when I started with a fresh install of my local npm modules, I get the following message from vs-code when I start it up:

Regardless if I choose "workspace version" or "bundled version", when restarting it fails to find tslint. 😢

[nchen63]

maybe it's a yarn vs npm issue

[ksnyde]

well it's possible but I did consider that and have tested with both npm install and yarn install

[nchen63]

I tested this on a new macbook pro which did not initially have npm, and it worked for me.

[nsgundy]

I just ran into the same issue... was using YARN. Turns out that the issue for me was that I at some point ran yarn clean so I had a .yarnclean file. You probably can guess where this is going... test was one of the directories to clean. Excluded that entry from .yarnclean, removed node_modules and rerun yarn and now all is good.

Not sure what the best course of action is... either for yarn to remove test from their default .yarnclean or to rename the folder.

[nchen63]

@nsgundy thanks. Closing this ticket since there's nothing else for us to do here.