Squash those bugs

This is a talk that I gave in a JS Roundabout meetup about bugs and how we deal with them at Nested. I covered the basics of what a bug is, why you will inevitably introduce bugs in your code and then talked about how to maintain a “bug free” codebase in practice.

Environmental variable for error reporting

I have briefly mentioned that using NODE_ENV for error reporting should be avoided and replaced by a separate environmental variable to toggle error reporting, but haven’t gone into too much detail about it. Below I explain the reasoning behind it.

In our case, we have different builds for development and production versions of the app. This is because with development build we want to optimise for developer experience — efficient builds and rebuilds, hot reloading and the likes. On the other hand, our production build focuses on a good user experience — small bundle size with efficient application performance. Having 2 different builds that are easily toggled between using NODE_ENV variable means that both developers and users can get a tailored experience suiting the particular needs of the situation.

The fact that the app that is in production is built in a slightly different way also means that we need to test that it still does what we intended it to do during the development stage. We test this manually while we configure the build and then we run our end-to-end tests against a production build of the app. If we were to use NODE_ENV as a determining factor whether to report errors or not, each mistake encountered in a local environment or each failing end-to-end test would send an error report. These reports would be pure noise, because we were already notified of this by the error in the console or a failing test. Therefore, we should reduce the noise and explicitly switch error reporting to true when no other tool would report them. This is how REPORT_ERRORS variable was born.

On a similar note, if analytics were tied to the environment, we would report analytics while configuring the production build or from our end-to-end tests. These reports would skew the actual metrics. Therefore, we also use REPORT_ANALYTICS to explicitly switch analytics reports to true when we want these reports to be sent.