Also, does this work over ipfs-api? (i.e with a daemon on?)

• work with the daemon on (through js-ipfs-api) Adds wiring for a progress bar ipfs-inactive/js-ipfs-http-client#596
• works for folders
• tests

@dignifiedquire @diasdavid

Testing the progress bar

There is now:

• a unit test for the progress bar in js-ipfs.
• tests in js-ipfs-unixfs-engine
  to test that a function passed with options.progress to the Importer is called with the right payload
• tests in js-ipfs-api to test that the progress function is called with the daemon running

What I tried to do yesterday was hook into progress.stdout and verify that the progress bar was being printed to the terminal.
I did manage this - is very sketchy and I decided to not submit it.

When the tests run progress.stdout is passed to the progress bar library but stdout.isTTY (is node a text terminal) is false so the library returns early and doesn't output anything.

To get the progress bar to output in tests means you have to highjack stdout in the tests and stub out the following:

• isTTY = true
• columns = 80
• cursorTo = function () {}
• clearLine = function () {}

Then the progress bar is piped to out most of the files add tests break because what is written to stdout has changed. Before starting to re-created a clearLine function to conditionally clear the progress bar once it is complete one has to stop and ask one's self. What am I doing here? This is a bit of a rabbit hole and I think the tests we have for the progress bar are sufficient.

However I can see the testing coverage has now fallen 😞

Now done through #1036