Replies: 3 comments 2 replies
-
|
+1 to bring back namespace inference. while not critical, it was convenient to not have to spell out the same namespace/scope every time. this also aligned with pnpm's
That said, I do see how the original implementation—particularly with a zero exit code—is potentially problematic. Off the top of my head, when multiple packages match a non-wildcard'd name, I'd assume turbo to either invoke all matching packages, or error out with a non-zero exit code. Eating my own words: I checked to see how |
Beta Was this translation helpful? Give feedback.
-
|
Hey, thanks for the idea! 8137 is the fix for many ambiguous behaviors through I can understand how, at a surface level, this change feels inconvenient, but it delivers a more consistent experience.
Overall, it's a tradeoff between correctness and convenience, and this is a place where correctness is the right call. You also may be interested in Automatic Package Scoping if you're not leveraging that feature yet, so you don't have to type any filter at all in many cases. |
Beta Was this translation helpful? Give feedback.
-
|
Cheers for indulging and sharing all the extra context! It sounds like you've seen more issues arise from the inference, so this feature was more trouble than it's worth. Speaking from experience, I can see more correctness also help out newcomers. When we first adopted turbo a while ago, I remember being confused why Bit unfortunate to see it go, but we'll get used to it in no time (especially once command history catches up). |
Beta Was this translation helpful? Give feedback.
-
|
I feel like your reply misses the point, @anthonyshew. If you're going to take away a convenience that already exists, you should replace it with something. I.e.:
I understand that taking away functinoality reduces bugs.. that's how deleting code works in general and I it's not something that should be celebrated. I feel like this discussion isn't talking about what you've |
Beta Was this translation helpful? Give feedback.
-
|
I understand that the functionality was removed. That was the goal and why it was a part of a major upgrade. 😄 The more important thing is that now, despite the inconvenience, the behavior is more correct, according to the user feedback we'd received. We knew that there would be a group that didn't appreciate the change, as well, and I understand why. I wish we could make everyone happy at all times, but this is the sort of thing that we have to asses the tradeoffs and make a decision for the betterment of the project. We tested this on ourselves and users who gave us feedback on pre-release canaries. We all used it for long enough before we realized it was the right choice. We did go through a period of being mildly annoyed but, after adjusting our habits, figured out that it's a good change for the long-term. As far as the suggestions you've made go, I'm not sure that they're viable given that they don't answer to the original reasons for the change. Additionally, there'd be added overhead on developers to know if you could use the namespace inference depending on which Turborepo you're in. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Goals
To let users avoid writing full package scope.
Non-goals
Break existing workflows
Background
This PR is pretty unpopular: #8137
Proposal
Bring back the scope detection functionality. Make it better though, so that conflicts have a deterministic behavior.
Beta Was this translation helpful? Give feedback.
All reactions