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

Adds optional permission timeout #35

Merged
merged 2 commits into from
Sep 18, 2015

Conversation

mex
Copy link
Contributor

@mex mex commented Sep 17, 2015

Adds the option to pass along permissionTimeout during init, which will let the permission prompt fall back to opt out after X seconds.

@sindresorhus
Copy link
Member

Why?

@mex
Copy link
Contributor Author

mex commented Sep 18, 2015

To give tools implementing this module the option to gracefully allow their users to skip the permission prompt instead of blocking indefinitely.

@sindresorhus
Copy link
Member

It only asks when interactive, meaning when a user is executing it. When non-interactive it will gracefully not show =>

if (!process.stdout.isTTY || process.argv.indexOf('--no-insight') !== -1) {
You can also use the --no-insight flag.

Why exactly does this not work for you?

@mex
Copy link
Contributor Author

mex commented Sep 18, 2015

Because checking for interactive doesn't catch all non-user-executed cases, as seen in common CI tools such as Bower.

@sindresorhus
Copy link
Member

Because checking for interactive doesn't catch all non-user-executed cases, as seen in common CI tools such as Bower.

Cases like? Please provide an actual example. This might be useful, but I'm not going to add something until I see actual use-cases, not just your words.

@mex
Copy link
Contributor Author

mex commented Sep 18, 2015

An example can be seen here: bower/bower#1102
The prompt broke thousands of builds, which this PR could prevent.

I know that users could just call the script with the interactive=false flag, but as seen in the issue and the search for "bower install" in GitHub repositories, a lot of users don't do this.

@sindresorhus
Copy link
Member

Alright. Not interested in an option, but we can add a default timeout of 30 seconds.

We can also a check for process.env.CI to fix the CI case completely: https://github.com/yeoman/insight/blob/master/lib/index.js#L104

@mex
Copy link
Contributor Author

mex commented Sep 18, 2015

I've removed the option for the timeout, defaulted to 30 and added test for this.

I also added a process.env.CI check in a separate commit.

@@ -38,6 +38,8 @@ function Insight (options) {
clientId: options.clientId || Math.floor(Date.now() * Math.random())
});
this._queue = {};

this.permissionTimeout = 30;
Copy link
Member

Choose a reason for hiding this comment

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

this._permissionTimeout = 30;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right! Fixed.

sindresorhus added a commit that referenced this pull request Sep 18, 2015
@sindresorhus sindresorhus merged commit aafb0d7 into yeoman:master Sep 18, 2015
@sindresorhus
Copy link
Member

Looks good. Thanks :)

@mex
Copy link
Contributor Author

mex commented Sep 18, 2015

Great! Can you ping me, when you bump the version?

@sindresorhus
Copy link
Member

Done

@mex
Copy link
Contributor Author

mex commented Sep 18, 2015

Awesome, thanks for the prompt reaction!

@sheerun
Copy link

sheerun commented Sep 18, 2015

@mex Doesn't it trigger callback two times if user answered before timeout?

@mex
Copy link
Contributor Author

mex commented Sep 18, 2015

@sheerun No, because we clear the timeout, when an answer is given:

clearTimeout(permissionTimeout);

@sheerun
Copy link

sheerun commented Sep 18, 2015

Oh, right :)

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.

None yet

3 participants