Clarification on Transit Nodes docs #9181
Conversation
turbo-orchestrator
bot
added
area: docs
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 6 Skipped Deployments
|
|
@maschwenk is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
| @@ -326,30 +326,30 @@ Some tasks should always be ran no matter what, like a deployment script after a | |||
|
|
|||
| Some tasks can be ran in parallel despite being dependent on other packages. An example of tasks that fit this description are linters, since a linter doesn't need to wait for outputs in dependencies to run successfully. | |||
There was a problem hiding this comment.
Alternatively you could change the above example to be typechecking instead, but based on this dissonance I'm actually a little confused by your example. Using Internal Packages™
since a type checker doesn't need to wait for outputs in dependencies to run successfully
could be true. Not using Internal Packages, where the output is .d.ts files, it would seem like you definetly can't typecheck package A if package B could be changing .d.ts files.
|
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
| } | ||
| } | ||
| ``` | ||
|
|
||
| This runs your tasks in parallel - but doesn't account for source code changes in dependencies. This means you can: | ||
|
|
||
| 1. Make a breaking change to the interface of your `ui` package. | ||
| 2. Run `turbo check-types`, hitting cache in an application package that depends on `ui`. | ||
| 2. Run `turbo lint`, hitting cache in an application package that depends on `ui`. | ||
|
|
||
| This is incorrect, since the application package will show a successful cache hit, despite not being updated to use the new interface. Checking for TypeScript errors in your application package manually in your editor is likely to reveal errors. |
There was a problem hiding this comment.
I guess if I change to lint here, now these references to Typescript need changing. So probably need to understand intent better to proceed.
| @@ -326,30 +326,30 @@ Some tasks should always be ran no matter what, like a deployment script after a | |||
|
|
|||
| Some tasks can be ran in parallel despite being dependent on other packages. An example of tasks that fit this description are linters, since a linter doesn't need to wait for outputs in dependencies to run successfully. | |||
There was a problem hiding this comment.
| Some tasks can be ran in parallel despite being dependent on other packages. An example of tasks that fit this description are linters, since a linter doesn't need to wait for outputs in dependencies to run successfully. | |
| Some tasks can be ran in parallel despite being dependent on other packages. An example of tasks that fit this description are linters or type checkers, since a these tasks doesn't need to wait for outputs in dependencies to run successfully. |
Technically, TypeScript as a type checker is a linter. But I can see how that would be confusing. Would this change be clearer?
There was a problem hiding this comment.
Yeah that works!
But I guess it feels like a more confusing example given my comment above:
When NOT using Internal Packages, where the output of each package is
.d.tsfiles, it would seem like you definetly can't start typechecking package A (which depends on B) until package B emits its.d.tsfiles
There was a problem hiding this comment.
Sorry, missed that. You're right, let's swap the example to being lint.
Description
I'm confused why this example starts off talking about linting and then the example it gives is called
check-typesand sounds very much like typechecking.Unsure which one is right but it feels like it'd be better to be consistent?
Testing Instructions
Use your eyes, your intellect, and your heart