Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[turborepo] Workspace packages not found if located behind symlink #2517

Open
blorgon1 opened this issue Oct 31, 2022 · 9 comments · May be fixed by #8120
Open

[turborepo] Workspace packages not found if located behind symlink #2517

blorgon1 opened this issue Oct 31, 2022 · 9 comments · May be fixed by #8120
Assignees
@chris-olszewski
Labels
kind: bug Something isn't working

Comments

@blorgon1
Copy link

blorgon1 commented Oct 31, 2022 •
edited
Loading

What version of Turborepo are you using?

1.6.2

What package manager are you using / does the bug impact?

pnpm

What operating system are you using?

Linux

Describe the Bug

When the path to a workspace package contains a symlink, turborepo can't find the package. I am using submodules for some of my workspace packages, and would like to keep all submodules in the same directory, while still linking them into the desired locations.

My repo is set up like this:

apps/
  app-a/
    package.json
      |-> widget-a@*
widgets/
  widget-a -> ../submodules/widget-a
submodules/
  widget-a/
    package.json

With a pnpm-workspace.yaml like this:

packages:
  - "apps/*"
  - "widgets/*"

Then when building app-a, this error is encountered:

Cannot find module 'widget-a' or its corresponding type declarations.

Without using the symlink (placing the submodule in the widgets directory), the build passes as expected.

This behaviour differs from pnpm, as pnpm is still able to locate the workspace packages behind a symlink:

> pnpm ls --depth -1 -r
/project/dir

[email protected] /project/dir/apps/app-a

[email protected] /project/dir/widgets/widget-a

Expected Behavior

Packages should be found when they are located behind symlinks. The behaviour should be identical to when the package is in place of the symlink.

To Reproduce

Move a workspace package to a different location (within the same project folder, just not in a workspace package path), and place a symlink to it in the original location.

Reproduction Repo

https://github.com/blorgon1/turbo-symlink-repro
@blorgon1 blorgon1 added the kind: bug Something isn't working label Oct 31, 2022
@chris-olszewski
Copy link
Member

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.

@blorgon1
Copy link
Author

Hi @chris-olszewski, thanks for your response.

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

@chris-olszewski
Copy link
Member

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

@nathanhammond
Copy link
Contributor

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

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

@blorgon1
Copy link
Author

blorgon1 commented Nov 1, 2022

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!

@chris-olszewski chris-olszewski self-assigned this Nov 9, 2022
@pc-erin
Copy link

pc-erin commented Nov 3, 2023

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.

@psychobolt psychobolt mentioned this issue Dec 31, 2023
Closed
1 task
@andymac4182
Copy link

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.

@chris-olszewski chris-olszewski linked a pull request May 9, 2024 that will close this issue
Draft
@moekify
Copy link

moekify commented Aug 15, 2024

@chris-olszewski is this still happening? :)

@sojimaxi sojimaxi mentioned this issue Sep 8, 2024
Closed
1 task
@muXxer muXxer mentioned this issue Sep 19, 2024
Closed
6 tasks
@Netail
Copy link

Netail commented Dec 31, 2024

Also experienced some issues regarding symlinks :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@chris-olszewski chris-olszewski

Labels
kind: bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: symlink workspaces vercel/turborepo
10 participants
@nathanhammond @mehulkar @andymac4182 @tknickman @chris-olszewski @Netail @moekify @anthonyshew @pc-erin @blorgon1