fix: validation for root turbo.json vs. Package Configurations #10610
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| @@ -1,7 +1,5 @@ | |||
| { | |||
| "$schema": "https://turborepo.com/schema.json", | |||
| "globalDependencies": ["foo.txt"], | |||
There was a problem hiding this comment.
Exactly the sort of thing we want to catch! Got caught here: https://github.com/vercel/turborepo/actions/runs/15958914313/job/45008819478
chris-olszewski
left a comment
There was a problem hiding this comment.
Just to reduce the overhead of keeping the disallow list up to date as we add fields, I think we should move to an allow list. This will probably mean splitting the TurboJson schema to be a root and package one where the package one is only extends and tasks.
|
Great point. Re-approaching it that way. |
| } | ||
|
|
||
| #[test] | ||
| fn test_allowlist_forces_explicit_categorization() { |
There was a problem hiding this comment.
Not sure if I want this test or not.
|
This really turned out to not be much fun at all. 😂 |
|
This has turned into needing pre-factors. Putting this in draft while I work on those. |
### Description Pre-work for #10610. Not all of our fields have spans, so we need to add them to get better at doing error reporting in some situations. --------- Co-authored-by: Chris Olszewski <chris.olszewski@vercel.com>
|
We did some other pre-work which invalidates this one! |
Description
We weren't checking fields that are root
turbo.json-only aren't being used in Package Configurations - and vice versa. I did a check of this nature in #10590 and have refactored that to a function that we can now use for other fields. Additionally, I've brought that idea along to the reverse situation.Testing Instructions
Added some tests ensuring the desired logic is what happens.