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

Clarification on Transit Nodes docs #9181

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+9 −9
Open

Clarification on Transit Nodes docs #9181

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions docs/repo-docs/crafting-your-repository/configuring-tasks.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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?

Copy link
Contributor Author

@maschwenk maschwenk Sep 24, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.ts files, it would seem like you definetly can't start typechecking package A (which depends on B) until package B emits its .d.ts files

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, missed that. You're right, let's swap the example to being lint.


Because of this, you may be tempted to define your `check-types` task like this:
Because of this, you may be tempted to define your `lint` task like this:

```json title="./turbo.json"
{
"tasks": {
"check-types": {} // Incorrect! // [!code highlight]
"lint": {} // Incorrect! // [!code highlight]
}
}
```

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.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess if I change to lint here, now these references to Typescript need changing. So probably need to understand intent better to proceed.


Because of this, you make a small change to your `check-types` task definition:
Because of this, you make a small change to your `lint` task definition:

```json title="./turbo.json"
{
"tasks": {
"check-types": {
"dependsOn": ["^check-types"] // This works...but could be faster! // [!code highlight]
"lint": {
"dependsOn": ["^lint"] // This works...but could be faster! // [!code highlight]
}
}
}
Expand All @@ -365,10 +365,10 @@ To meet both requirements (correctness and parallelism), you can introduce [Tran
"transit": {
"dependsOn": ["^transit"]
},
"check-types": {
"lint": {
"dependsOn": ["transit"]
},
},
}
}
}
```

Expand Down
Loading