Start script + watchers need to be more verbose

[TejasQ]

File in Question https://github.com/contiamo/operational-ui/blob/a432c8e90277345b31e11ec30fb02599ddaf7e77/scripts/start.ts#L1-L137

Currently, yarn start doesn't really output errors (probably because styleguidist reports errors on something other than stderr). As a result, errors are swallowed and we just see infinite spinners.

More context in this issue.

Let's fix this by reporting and even process.exit(1)ing when styleguidist fails.

[aliahsan07]

Hey, I'm an opensource newbie, can I take up this issue?

[TejasQ]

Are you comfortable with Node.js and CLIs? This is a little bit different to the rest of the issue so on this project. If you feel confident, let’s do it. 💪🏾

[aliahsan07]

I am. I wouldn't say I'm experienced with CLI's but I've started to prefer them over GUI's

[TejasQ]

Cool. Do it.

[aliahsan07]

is there a guide to how the errors must be reported?

[TejasQ]

Nope. Get creative 🤠 🖌 🎨 .

I like the ones from TypeScript and all of @zeit and @prisma's stuff 😍

[TejasQ]

Hey @aliahsan07! How are you fairing with this? Do you have a plan? Want some direction/help?

[aliahsan07]

basically trying to play with styleguidist, see how it reports errors. Any leads on where should I look into?

[TejasQ]

Since we use Ora, you could spinner.fail() and then process.exit(1) when styleguidist fails.

This is where we're currently failing: https://github.com/contiamo/operational-ui/blob/a432c8e90277345b31e11ec30fb02599ddaf7e77/scripts/start.ts#L76-L78

Styleguidist does not fire an error event in its process when there is one and so our process continues executing. Maybe it just exits? In that case, maybe we should reject the promise on executor.on('exit' in this case.

I'm not really sure but these ideas might point you in the right direction. Thoughts? Questions?

[aliahsan07]

it never seems to reach the if (d === "\n") { return } condition and hence is stuck inside and consequently promise is not rejected and the spinner loads forever.

[TejasQ]

That's a great first step. Have you read my previous comment? Do you have a plan to fix it?

[aliahsan07]

sorry for the long delays Yes, I've read your comment, the plan is to reject the promise and halt the spinner when the error occurs. There is something I haven't quite figured out about the issue with styleguidist and I'm hoping I'll play around for a while before I have a concrete understanding of it, shouldn't take long

[TejasQ]

Nice! Please feel free to ask any questions you have if you feel like our help might be faster than poking around docs.

[aliahsan07]

I can't seem to deduce if there is an error which is getting eaten up and not being reported to the stdout. The react-styleguidist eventually compiles (~5 minutes), and the loader stops. The application can then be accessed.

Is this really an issue of errors not visible to the console or just styleguidist taking too long? Please guide me if I'm mistaken. I've looked carefully at what's getting passed to the reader stream, at one point I get an empty string, that's when loader takes a long time, but after that, the 'compiled successfully' string appears which resolves the promise and ceases the spinner.

[TejasQ]

It succeeds in your case! This is great! It fails in other cases. I think a good option is to explicity create a styleguidist error (have odd syntax in one of the src components) and then try to start the dev server. This should fail, and you likely won't be able to see an error. This is what we're trying to fix. 😄

[aliahsan07]

I'm officially stuck. I created a syntax error and hence a result the styleguidist doesn't compile. Going through the styleguidist source code, the syntax error is supposed to be reported by this function in the type === 'error' if condition, but it's consumed and not shown on the stderr.

function printStatus(text, type) { if (type === 'success') { console.log(kleur.inverse().bold().green(' DONE ') + ' ' + text); } else if (type === 'error') { console.error(kleur.inverse().bold().red(' FAIL ') + ' ' + kleur.red(text)); } else { console.error(kleur.inverse().bold().yellow(' WARN ') + ' ' + kleur.yellow(text)); } }

What I did was I tried to wrap our readable stream in a try catch block, believing that when the error event fires, it will be caught in the catch block but it doesn't. It seems like the readable stream is still waiting for data to fire. Neither the exit nor the error event fires and that's confusing me.

[TejasQ]

What about the end event? Sometimes people pipe errors there...