Ts-morph: project.getSourceFiles() filtering not working in v11

[MohamedLamineAllal]

Describe the bug

Version: 11.0.3

project.getSourceFiles() // return --> all files

Works just fine

project.getSourceFiles('**/*.ts') // return -> [] (doesn't get the files)

project.getSourceFiles('exact/file/path/to/file') // return -> [] (doesn't get the files)

project.getSourceFile('exact/file/path/to/file') // return -> undefined (doesn't get the file)

This doesn't.

To Reproduce

const projectDirectory = '/someDirectory'
const projectConfigFile = path.join(projectDirectory, 'tsconfig.json')
const project = new Project({
    tsConfigFilePath: projectConfigFile,
})

const sourceFilesAll = project.getSourceFiles() // return --> [...source files (all)...]
const sourceFilesFiltered = project.getSourceFiles('**/*.ts') // return --> [] (empty)

Expected behavior

Filters should just works well!

[dsherret]

Could you provide more details and something I could take to reproduce this? I’m not sure what files exist in that project. What you’re doing should work. Perhaps the current working directory is different and you need to do ${projectDirectory}/**/*.ts

[MohamedLamineAllal]

Thanks for the fast reply! And the amazing work done in this library. I just tested! it's what you said!

I'm loading the project from another directory!

const sourceFile = project.getSourceFiles(`${projectDirectory}/**/config/index.ts`)

That's working well.

Why such a behavior ?

if it was to compare directly to paths! the glob should match just right ( i did that in a filtering function i made using minimatch )!

Shouldn't normally the matching go automatically relatively to the project directory ?

No files beyond the one loaded in the project will be attainable.

Thank you again. I'm wondering if matching relatively to the project is what it should be. Why it's the way it is ?

Also i would like to add such a detail to the source files documentation. I Would add a small block if it's right ? That can save good time for many. is contribution to documentation acceptable ?

[dsherret]

Why such a behavior ? ... Shouldn't normally the matching go automatically relatively to the project directory ?

It's done this way because then all the paths use the same directory as the base including at project initialization. Additionally, when you use project.getFileSystem() everything will be relative from the cwd. I don't believe it would make sense to make it relative based on the directory of the tsconfig once you initialize. For example, say there was the following structure and the cwd was the root:

/project1
  tsconfig.json
  mod.ts
/project2
  tsconfig.json
  mod.ts
/project3
  mod.ts

I'm not sure it would be desirable to work this way:

const project = new Project({ tsConfigFilePath: "./project1/tsconfig.json" }); // relative CWD
project.addSourceFilesFromTsConfig("../project2/tsconfig.json"); // relative from project1
project.addSourceFiles("../project3/**/*.ts"); // relative from project1

I would expect the current behaviour:

const project = new Project({ tsConfigFilePath: "./project1/tsconfig.json" }); // relative CWD
project.addSourceFilesFromTsConfig("./project2/tsconfig.json");  // relative CWD
project.addSourceFiles("./project3/**/*.ts"); // relative CWD

Also i would like to add such a detail to the source files documentation. I Would add a small block if it's right ? That can save good time for many. is contribution to documentation acceptable ?

Sure, thanks! That would be great to add something saying that it's based on the current working directory.

[MohamedLamineAllal]

Thanks.

That clear it up! I didn't consider multiple tsconfig files. I think it's great as it is. And anything else like for example a virtual filesystem ( All added files will be mapped to a virtual base. And then any search and access go from the base, someDiro/Diro2/ That going from virtual root. And here file collision can happen, one can have mapping.). But as it is, is efficient and strong. I will add this detail to the doc.

Big Thanks again.

[MohamedLamineAllal]

I added a mention for this in the doc. PR 1186