Consider a temporary node_modules installation for dtslint

[cartant]

Bug Report

Current Behavior

There is a problem that sometimes occurs with dtslint. In particular, it usually occurs on Travis and usually occurs around the time of a TypeScript release (AFAICT).

When dtslint runs, it installs a bunch of TypeScript versions underneath its own directory in node_modules. It seems that using a lock file sometimes cause errors like this:

> @reactivex/rxjs@6.3.1 dtslint /home/travis/build/ReactiveX/rxjs
> dtslint spec-dtslint
module.js:549
    throw err;
    ^
Error: Cannot find module 'definitelytyped-header-parser'
    at Function.Module._resolveFilename (module.js:547:15)
    at Function.Module._load (module.js:474:25)
    at Module.require (module.js:596:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/home/travis/build/ReactiveX/rxjs/node_modules/dtslint/bin/index.js:12:41)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)
    at Module.load (module.js:565:32)
    at tryModuleLoad (module.js:505:12)
    at Function.Module._load (module.js:497:3)

It seems that the error is effected because whatever dtslint downloads expects to be run in the presence of dependencies that are up-to-date and not pinned by a lock file.

My workaround for this is to update the lock file using:

npm uninstall dtslint --save-dev ; npm install dtslint --save-dev --save-exact

And to then push the updated lock file in a commit. I've used this procedure to fix the error on several occasions.

Possible Solution

Given that dtslint downloads modules when it runs and doesn't expect its dependencies to be pinned, it might be better to use a separate, temporary node_modules installation for dtslint itself.