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
chore: remove turbo for now #5978
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
No changes to documentation |
Component Testing Report Updated Mar 12, 2024 8:18 PM (UTC)
|
81a37a4
to
77b6b43
Compare
77b6b43
to
4642dbd
Compare
4642dbd
to
d2a5f53
Compare
815ae2b
to
3db0349
Compare
🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎ To accept the risk, merge this PR and you will not be notified again.
Next stepsWhat is an install script?Install scripts are run when the package is installed. The majority of malware in npm is hidden in install scripts. Packages should not be running non-essential scripts during install and there are often solutions to problems people solve with install scripts that can be run at publish time instead. Take a deeper look at the dependencyTake a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev. Remove the packageIf you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency. Mark a package as acceptable riskTo ignore an alert, reply with a comment starting with
|
We don't want tsc build to emit JavaScript sources, as this is taken care of by pkg-utils
25df69b
to
cf09ec9
Compare
Description
We spent some time today tracking down a build issue that started happening after 4e72b80. However, this build error didn't get reflected as CI build failure, which made it hard to catch. Furthermore, while bisecting to try to pinpoint the offending commit, we found that the way turbo caches the build got in the way and added a lot of confusion to the process.
I'd like to remove turbo entirely for now until we can make sure that CI fails when it should, and only then carefully consider re-adding it if we can get the caching right.
What to review
Do you agree? Is there something obvious I'm missing about how this is supposed to work?
Notes for release
n/a