-
-
Notifications
You must be signed in to change notification settings - Fork 109
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
added suspending update renderer for task #136
base: master
Are you sure you want to change the base?
Conversation
lib/task.js
Outdated
} | ||
|
||
get subtasks() { | ||
return this._subtasks; | ||
} | ||
|
||
shouldSuspendUpdateRenderer() { | ||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you try/catching a boolean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I catching it, because task.options
can be undefined. Without catching it, it throws TypeError, if you don't supply any option.
@@ -43,12 +43,22 @@ class Task extends Subject { | |||
this.title = task.title; | |||
this.skip = task.skip || defaultSkipFn; | |||
this.task = task.task; | |||
this.taskOptions = task.options; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is moot. You can already access it as this.task.options
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, but this.task
can be just a function. task.options
refers to input-variable task
given in the constructor and not to this.task
. We will need here a separate variable to store the options.
The new option should be documented and tested. |
@sindresorhus: The diffs in the other files are coming from the command |
Codecov Report
@@ Coverage Diff @@
## master #136 +/- ##
===========================================
- Coverage 96.31% 78.35% -17.97%
===========================================
Files 7 7
Lines 190 194 +4
===========================================
- Hits 183 152 -31
- Misses 7 42 +35
Continue to review full report at Codecov.
|
@sindresorhus: |
Anyone interested to review this pull-request and the affiliated pull-request 137? |
test/concurrent.js
Outdated
@@ -1,8 +1,8 @@ | |||
import {serial as test} from 'ava'; | |||
import delay from 'delay'; | |||
import Listr from '..'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you edit these files? They're out of the scope of this PR anyways, and the imports were fine the way they were.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes come from xo --fix
command. I remove them in my next commit.
test/suspend.js
Outdated
console.log(text); | ||
} | ||
}; | ||
logUpdateApi.main.clear = function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should create a noop function (e.g. const noop = () => {};
) and use it here and below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I imported the log-update
-module directly. This section now should be refactored.
test/suspend.js
Outdated
mockery.enable({useCleanCache: true, warnOnUnregistered: false}); | ||
}); | ||
|
||
test('should suspend second task', async t => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't test use-cases where suspendUpdateRenderer
is actually needed. There should be a test(s) for that as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intention was to create two task. The first task without the option suspendUpdateRenderer
. So the update renderer should display status "task 1 pending" exactly one time. The second task with the option suspendUpdateRenderer
. So the update renderer shouldn't display status "task 2 pending", because it is suspended. If the suspend-function doesn't work as expected, the update renderer displays "task 2 pending" more than once, because we have a timeout of 4s.
You could simply try it, when cloning my fork listr
locally. With the current version of listr-update-renderer, the tests fail. With linking my fork of listr-update-renderer
the tests pass.
What tests you thought of? Integration-tests, which ask for user input or tests, which mock listr-update-renderer
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I thought of is a test case in which the suspension is actually required, meaning that the test won't pass if the task isn't suspended (and only passes if it is).
(Even if the mock isn't called, that doesn't really mean much. We want the test to verify correct behavior, not logic.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added now a custom renderer mock, which output is excatly verified. It only passes, if suspension is activated.
When the mock isn't called with the correct args, the test fails.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry to keep bothering you, but this is still not what I meant in my comments above.
As I recall, the reason we need this in np is since one of the commands we call waits for the user to enter a password, which we need to receive before moving on to the next task.
This test, again, only verifies we correctly pass on the suspendUpdateRenderer
option from here to the Listr renderer (let me know if I'm mistaken, though).
I think that the simplest way to test this would be to actually run a command that waits for user input, then verify we do receive it when suspendUpdateRenderer
is set to true
(and don't when it's set to false
, as the task isn't suspended).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem isn't, that the task can't receive the user-input from stdin
. The task actually receives the input from stdin
independently of suspendUpdateRenderer
. The problem is, that listr-update-renderer
erases password-prompts on stdout
. For the user it looks like the prompt never appears and the task is running infinite.
What we need to check is, that the task-output is not erased by the log-update
-module, when a task with suspended renderer is running. I have done that in my actual version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@itaisteinherz
Btw i added the testclass task-with-input
, which proves, that the input from stdin
is available for every task, no just for the tasks with suspended renderer.
1. Refactoring test-classes and readme 2. play back import order
@itaisteinherz or @LitoMore |
@bunysae Thank you so much! I will review your PR in few days. |
@LitoMore @SamVerschueren Bump :) |
In order to fix issue np issue 79, these changes add an optional suspend-flag for every task.
The suspend-flag is later used, to suspend the listr-update-renderer.