Adding .d.ts files into project no longer works in v24

[B4nan]

Describe the bug

Version: 24.0.0

To Reproduce

We use ts-morph inside MikroORM to allow inference of property types from TS files. In production environment, we used .d.ts files instead of .ts to do this. This is the part that adds the files to the project:

https://github.com/mikro-orm/mikro-orm/blob/master/packages/reflection/src/TsMorphMetadataProvider.ts#L245

A complete reproduction for this problem is provided in mikro-orm/mikro-orm#6297, I can try to narrow it down if that's not enough. Reverting ts-morph to v23 resolves the problem.

I've started debugging this from inside the docker container, and I can see that when we try to add the .d.ts files into the project via this.sources = this.project.addSourceFilesAtPaths(paths), it's apparently a no-op, since calling console.log(this.sources.map(s => s.getFilePath())) gave me an empty array.

The inputs for addSourceFilesAtPaths are as follows:

[
  '/dist/shared/crud/crud.entity.d.ts',
  '/dist/apis/user/entities/user.entity.d.ts',
  '/dist/shared/crud/base.entity.d.ts',
  '/dist/apis/user/entities/test.entity.d.ts'
]

I verified all the files are present on those paths inside the container. The app is in the root of the container. Note that the error message you can see when you run that app says the .ts file was not found, but internally we check both .ts and .d.ts files, and only report the former, so it's not about that.

I hope this can be enough for you since all the ts-morph handling is part of that single TsMorphMetadataProvider class (which is fairly simple), but I can surely try to reproduce this without the ORM involved too.

Expected behavior

Same behavior as v23, .d.ts files should be added to the project.

My hunch is it was caused by #1558. I tried to update TS to 5.6 and 5.7 in that project and that itself didn't help.

[B4nan]

A bit more details about this, tried logging the inputs here:

ts-morph/packages/ts-morph/src/fileSystem/DirectoryCoordinator.ts

Line 65 in 061a3fe

for (const filePath of this.#fileSystemWrapper.globSync(fileGlobs)) {

With console.log('addSourceFilesAtPaths', fileGlobs, options, [...this.#fileSystemWrapper.globSync(fileGlobs)]) I am getting:

addSourceFilesAtPaths [
  '/dist/shared/crud/crud.entity.d.ts',
  '/dist/apis/user/entities/user.entity.d.ts',
  '/dist/shared/crud/base.entity.d.ts',
  '/dist/apis/user/entities/test.entity.d.ts'
] { markInProject: true } []

Also when I do ls -l /dist/shared/crud I see the files:

de63e2b98890:/# ls -l /dist/shared/crud
total 48
-rw-r--r--    1 node     node            87 Dec 14 11:04 base.entity.d.ts
-rw-r--r--    1 node     node          1737 Dec 14 11:04 base.entity.js
-rw-r--r--    1 node     node           554 Dec 14 11:04 base.entity.js.map
-rw-r--r--    1 node     node           229 Dec 14 11:04 crud.entity.d.ts
-rw-r--r--    1 node     node          2426 Dec 14 11:04 crud.entity.js
-rw-r--r--    1 node     node           983 Dec 14 11:04 crud.entity.js.map
-rw-r--r--    1 node     node           246 Dec 14 11:04 crud.repository.d.ts
-rw-r--r--    1 node     node          1158 Dec 14 11:04 crud.repository.js
-rw-r--r--    1 node     node           328 Dec 14 11:04 crud.repository.js.map
-rw-r--r--    1 node     node           604 Dec 14 11:04 crud.service.d.ts
-rw-r--r--    1 node     node          3428 Dec 14 11:04 crud.service.js
-rw-r--r--    1 node     node          1168 Dec 14 11:04 crud.service.js.map

So far I cannot make it fail this way in the ORM test suite itself, I can only see this inside the docker image.

When I downgrade ts-morph to v23 inside it, the same logs are correctly adding the files to the project:

addSourceFilesAtPaths [
  '/dist/shared/crud/crud.entity.d.ts',
  '/dist/apis/user/entities/user.entity.d.ts',
  '/dist/shared/crud/base.entity.d.ts',
  '/dist/apis/user/entities/test.entity.d.ts'
] { markInProject: true } [
  '/dist/shared/crud/crud.entity.d.ts',
  '/dist/shared/crud/base.entity.d.ts',
  '/dist/apis/user/entities/user.entity.d.ts',
  '/dist/apis/user/entities/test.entity.d.ts'
]

[dsherret]

It's weird. I think I'm just going to revert that PR. I'd rather have stability.

[benmccann]

Sorry for the breakage. I believe this issue was just fixed in tinyglobby: SuperchupuDev/tinyglobby@a4820cc. A test was added as well to prevent regressions

Definitely agree that correctness is more important than size and speed. Hopefully we can achieve both here though. I'd love if we could try the next version of tinyglobby when it is released and confirm that it fixes the issue here.

tinyglobby is used by massive projects like Vite and eslint-import-resolver-typescript, so there's not a ton of hidden bugs in it. The author is super responsive as you can see by how quickly this issue was addressed.

[B4nan]

Sorry for the breakage. I believe this issue was just fixed in tinyglobby: SuperchupuDev/tinyglobby@a4820cc. A test was added as well to prevent regressions

I tried to apply the patch locally and it did not help with this issue. Logging the cwd in there, and it's just /, escaping is not doing anything to it. It sounds like there is a problem with running this from inside root (which is quite common inside docker images).

[dsherret]

Released now in 25.0.0. Let's re-evaluate this once the issue is actually fixed.