Fix: Add conventions for Production vs Development log levels

[acunniffe]

Optic recently updated our version of mockttp, the latest of which comes with a known issue where an inner dependency uses a deprecated stream processor. While non-breaking, the node community has not been able to fully shift away from this deprecated functionality yet..

We want to make sure Optic contributors, and non-stable build users see every warning, because future warnings may indeed matter. But we also don't want to pollute production CLIs will warnings that those users don't need to worry about.

This PR starts looking for OPTIC_DEVELOPMENT in the environment. When you are developing Optic with the sourceme.sh aliases on your path, that variable is present in the environment, the effect of which is that you see all warnings. When this is missing (production builds) you won't see the node deprecation warnings.

There may well be other kinds of warnings we want to add to development only Optic builds, we will likely continue using OPTIC_DEVELOPMENT as the flag to turn this feedback on and off.

We'll continue tracking the mockttp issue and hope to move away from the deprecated functionality the dependencies rely on soon.

[JaapRood]

I think this is a good quick fix to make sure we still see warnings in development (as long as we're using sourceme.sh which sets the necessary env variable), but perhaps this is an opportunity to discuss whether we can use the more surgical --no-deprecation cli flag.

I imagine the run file could be:

#!/usr/bin/env bash

node --no-deprecation run.js

[devdoshi]

I think this is a good quick fix to make sure we still see warnings in development (as long as we're using sourceme.sh which sets the necessary env variable), but perhaps this is an opportunity to discuss whether we can use the more surgical --no-deprecation cli flag.

I imagine the run file could be:

#!/usr/bin/env bash

node --no-deprecation run.js

@JaapRood the issue is about not letting any warning impact the end user experience for our published artifacts, so not specifically about the node stream deprecation. Either way, if you feel like playing around with the shebang and multiple scripts let me know how that goes!

[JaapRood]

the issue is about not letting any warning impact the end user experience for our published artifacts, so not specifically about the node stream deprecation.

@devdoshi totally agree, but the way to do that is to make sure to not ship any warnings, not to just disable them. If anything, the chance that a warning might make it into the end-user experience is actually the drive / force needed to make sure warnings are handled promptly. Disabling warnings should be a last resort, when fixing isn't pragmatic, so the more surgical you can be about that disabling, the better.

I'll be getting back to this with priority when time allows, it smells pretty bad.