Hi @blorgon1, could you provide a reproduction repo? Module resolution is a responsibility of the package manager so it's odd that pnpm is able to find the package in ls but not whatever command you have set for building app-a.

Hi @chris-olszewski, thanks for your response.

Here is a reproduction repo: https://github.com/blorgon1/turbo-symlink-repro

Thanks for the repro! It looks like our globbing library isn't following symlinks. I should be able to get a fix up soon.

@chris-olszewski This was an intentional change introduced in 494b894

We need to make sure that we don't regress #1265.

Ah okay, that's unfortunate given that using a folder for submodules is a common practice.

From the fix commit message:

This caused us to copy their pointed-to contents as if the symlink was a directory, and then when copying the link itself, throw an error because it already existed (as a directory...).

It seems that an alternate solution would be to skip copying symlinks but still traverse them?

Anyways it's easy to work around, thanks for looking into it!

I'm having almost the same issue, but in my case it's caused by the symlink that npm creates to connect workspace dependencies. Do we need to manually copy and workspace dependencies to the output image in our dockerfile? This seems like the kind of default behavior that turbo repo should handle.

This is causing lots of issues for us :( I understand the reason for disabling symlinks but please at least give us an option to enable them again if we have a need to.