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.

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

fix: only enable interactivity if stdin is a TTY too #6437

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

paul-soporan
Copy link
Member

What's the problem this PR addresses?

Addresses #6419 (comment).

#6419 made Yarn non-interactive when the stdout isn't a TTY, but it makes sense to disable interactivity when the stdin isn't interactive too.

How did you fix it?

Made it check whether both stdout and stdin are TTYs before enabling interactivity.

This way both of the following commands will always be non-interactive:

  • yarn add lodash > foo.txt
  • echo '' | yarn add lodash

Checklist

  • I have set the packages that need to be released for my changes to be effective.
  • I will check that all automated PR checks pass before the PR gets reviewed.

@@ -1790,7 +1790,10 @@ export class Configuration {
return {os, cpu, libc};
}

isInteractive({interactive, stdout}: {interactive?: boolean, stdout: Writable}): boolean {
isInteractive({interactive, stdin, stdout}: {interactive?: boolean, stdin: Readable, stdout: Writable}): boolean {
Copy link
Member

Choose a reason for hiding this comment

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

This is a breaking change.

Copy link
Member Author

@paul-soporan paul-soporan Aug 11, 2024

Choose a reason for hiding this comment

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

🤔 Indeed, didn't realize 4.4.0 was released with the previous PR.

Given the fact that GH code search doesn't return anything for configuration.isInteractive and the change has only been out for one week, I'd say there's about a 0% chance that anybody is using it and would prefer to land this change before anybody gets the chance to use it, even though it's theoretically a breaking change.

Copy link
Member

Choose a reason for hiding this comment

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

It's probably fine but could we make it optional with a TODO note to fix it for the next major?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants