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.

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

fix: error when workspaces are not defined #472

Merged
merged 7 commits into from
Jan 10, 2022
Merged

fix: error when workspaces are not defined #472

merged 7 commits into from
Jan 10, 2022

Conversation

KarolNov
Copy link
Contributor

The workspaces are required for turborepo to work, but lack of them results in unfriendly error message that does not explain that. The PR may need some changes, that's just a quick fix you could use.

@vercel
Copy link

vercel bot commented Dec 31, 2021

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/vercel/turbo-site/8sdWJNJEGvtCJHZyGxVVub2RfHPn
✅ Preview: https://turbo-site-git-fork-karolnov-chore-log-lack-of-workspaces.vercel.sh

@vercel
Copy link

vercel bot commented Jan 10, 2022

@jaredpalmer is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

@jaredpalmer jaredpalmer changed the title Chore: log lack of workspaces fix: error when workspaces are not defined Jan 10, 2022
@jaredpalmer jaredpalmer added the pr: automerge Kodiak will merge these automatically after checks pass label Jan 10, 2022
@jaredpalmer jaredpalmer merged commit fe994bd into vercel:main Jan 10, 2022
sokra pushed a commit that referenced this pull request Oct 25, 2022
1. Takes advantage of `HashSet`s instead of `Vec`s for collections, since a TaskId could be seen multiple times
2. Avoids several `CountHashSet`->`Vec`->`CountHashSet` round trips during recursive `read_collectibles`
3. Moves taking collectibles into the backend, so that it can be performed before the state lock is released.

This alone doesn't solve my issue with logging. No matter what changes I've tried to the backend (`children` scopes crawling, collating into a `CountHashSet` during reads (because items could be very negative but still have a single positive elsewhere stack)), I constantly see the same message over and over.

I now think it's because the `turbopack-dev-server` is spawning new root tasks everytime it receives a network request. That root task is completely divorced from prior executions, so every time we've un-emitted, it's just re-emitted during the computation of the new root task's subtasks. I think we need to invert the network-handler -> turbo-tasks nesting to be turbo-tasks -> network-handler, with a persistent root task.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr: automerge Kodiak will merge these automatically after checks pass
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants