Ts-morph: Cannot find types if project folder is not cwd

[osyrisrblx]

Describe the bug

Version: 1.0.0

To Reproduce

Create a TS project folder with a simple tsconfig.json + some .ts files in a "src" folder.
Set the following options in tsconfig.json:

• "noLib": true,
• "types": [ "my-types" ],
  ( "my-types" should be an npm package with type declaration files)

import * as path from "path";
import { Project, ts } from "ts-morph";

const projectPath = "/absolute/path/to/project";
const tsConfigPath = path.resolve(projectPath, "tsconfig.json");

console.log(ts.version); // 3.3.1
console.log("tsConfigPath", tsConfigPath);

const project = new Project({
    tsConfigFilePath: tsConfigPath,
});

for (const diag of project.getPreEmitDiagnostics()) {
    console.log(diag.getMessageText());
}

Expected behavior

I expect the following output:

3.3.1
tsConfigPath /absolute/path/to/project/tsconfig.json

But if I run the code with the process.cwd() not being the project folder, I get the following instead:

3.3.1
tsConfigPath /absolute/path/to/project/tsconfig.json
Cannot find global type 'Array'.
Cannot find global type 'Boolean'.
Cannot find global type 'CallableFunction'.
Cannot find global type 'Function'.
Cannot find global type 'IArguments'.
Cannot find global type 'NewableFunction'.
Cannot find global type 'Number'.
Cannot find global type 'Object'.
Cannot find global type 'RegExp'.
Cannot find global type 'String'.
Cannot find type definition file for 'my-types'.

[dsherret]

@osyrisrblx hmmm that's strange! I would expect the second output both times though since noLib is true and I'm guessing my-types is located in node_modules/my-types rather than node_modules/@types/my-types. Perhaps the compiler api is searching in the node_modules of the current working directory to try to resolve types and that's why the first one finds the files.

[osyrisrblx]

@dsherret

I'm guessing my-types is located in node_modules/my-types rather than node_modules/@types/my-types

Yep.

https://www.typescriptlang.org/docs/handbook/tsconfig-json.html

This part of the documentation seems to indicate that "types" is just an array of package names to be included as type declarations.

[dsherret]

@osyrisrblx the documentation is not so great on this point. From my understanding, types are resolved out of the packages in typeRoots which by default is node_modules/@types (see the source: https://github.com/Microsoft/TypeScript/blob/b534fb4849eca0a792199fb6c0cb8849fece1cfd/src/compiler/moduleNameResolver.ts#L240).

Anyway, something strange is going on here. I'll look into it soon.

[dsherret]

@osyrisrblx

But if I run the code with the process.cwd() not being the project folder

Do you get these errors when process.cwd() is the project folder?

Cannot find global type 'Array'.
Cannot find global type 'Boolean'.
Cannot find global type 'CallableFunction'.
Cannot find global type 'Function'.
Cannot find global type 'IArguments'.
Cannot find global type 'NewableFunction'.
Cannot find global type 'Number'.
Cannot find global type 'Object'.
Cannot find global type 'RegExp'.
Cannot find global type 'String'.
Cannot find type definition file for 'my-types'.

Because I get those errors when the cwd is the project folder, which should be expected for both scenarios.

[dsherret]

Closing for now. @osyrisrblx please reopen when you have more details.

[osyrisrblx]

Hi @dsherret, sorry I forgot to get back to you on this!

No, I do not receive those errors because I have an npm package that supplies types for those.
( https://www.npmjs.com/package/rbx-types )

It seems like for whatever reason, if process.cwd() is _not_ my project folder, it cannot find the types in my node_modules folder. My tsconfig.json looks like this:

{
    "compilerOptions": {
        "allowSyntheticDefaultImports": true,
        "downlevelIteration": true,
        "module": "commonjs",
        "noLib": true,
        "strict": true,
        "target": "es6",
        "types": [ "rbx-types" ],

        "rootDir": "src",
        "outDir": "out",

        "baseUrl": "src",
        "declaration": false,

        "jsx": "react",
        "jsxFactory": "Roact.createElement"
    },
    "typeAcquisition": {
        "enable": true
    }
}

[dsherret]

I think it's not resolving for the reason I mentioned in my previous comment:

From my understanding, types are resolved out of the packages in typeRoots which by default is node_modules/@types (see the source: https://github.com/Microsoft/TypeScript/blob/b534fb4849eca0a792199fb6c0cb8849fece1cfd/src/compiler/moduleNameResolver.ts#L240).

I wonder if it would resolve it fine if rbx-types was in the typeRoots folder of node_modules/@types (so at node_modules/@types/rbx-types. I think it happens to resolve when it's in the cwd because typescript will search node_modules in the cwd as well, but yeah I'll look into it more again.

[osyrisrblx]

Hmm I tried manually moving node_modules/rbx-types into node_modules/@types/rbx-types, but that seems to still give me the same error. Even if I remove my types field in the tsconfig.json.

[dsherret]

@osyrisrblx ok, thanks for checking! I'll look into this again soon.

[dsherret]

@osyrisrblx I've discovered the issue here. There is a project compiler option I never knew about, but it's not used by the compiler api. Instead there's an internal configFilePath and setting that will fix the issue here.

So a temporary workaround is to do:

const project = new Project({
    tsConfigFilePath: tsConfigPath,
    compilerOptions: {
        configFilePath: tsConfigPath
    } as any
});

I will fix this internally in the library for 3.0.0 so no extra compiler options will be necessary. I've also opened an issue in the TypeScript repo about project not doing anything

[osyrisrblx]

Thanks for investigating! I'll use your fix for now.

[dsherret]

So, turns out the project option is only used by tsc and the configFilePath option was being set when parsing a tsconfig.json file, but I had this statement on the line below because I thought it didn't do anything (facepalm):

delete result.options.configFilePath;

Thanks so much for sticking through with me on this one @osyrisrblx and sorry it took a bit of time.

This will be resolved in 3.0.0.