parsing_an_error.md

Parsing An Error

Recently, I have seen a pattern of aspiring developers trying to debug without reading error messages. Yikes! Error messages, as huge, freaky and unruly as they might look, are actually your BEST FRIEND when debugging. Here is a guide to reading them!

In this demo repo, we will attempt to transpile JSX files in /src to JS files in /public. Provided is a script called compile, and one devDependency: @babel/cli.

Provided directories in this repo are /public and /src. /src contains the App.jsx file that we want to transpile. /public is empty.

So, let’s try running the compile script from our package.json:

Error! :(

This may seem disheartening, but this error message will likely be the key to resolving the bug. Let’s break this down:

Green Box: This contains data about the script NPM is running. This is not technically part of the error message, but it does contain potentially useful data.

• some-repo@1.0.0 represents the name of the repo and the version number defined in package.json
• compile is the name of the script being run
• /Users/johncastberg/code/hack-reactor/hrsf116/some-repo is the path to the repo’s directory
• babel src --out-dir public --presets @babel/preset-react --source-maps inline is the shell command that was executed as a result of running the script.

Red Box: This contains the line of code that the error occurred on.

• internal/modules/cjs/loader.js:651 is the filename (loader.js) and the line (651) that the error occured on
• throw err; is the part of the code that threw the error.

Purple Box: This contains the message associated with the error.

• Error: Cannot find module '@babel/core' Pretty self explanatory, this error occured because the module ‘@babel/core’ wasn’t found.

Blue Box: This contains the stack trace!

• Often times this will be the scariest looking part of the error. It may also be the most helpful. The stack trace shows the call stack at the time the error occurred, with the function call highest on the list being the most recently called function. Let’s break down the highest line: Function.Module._resolveFilename(internal/modules/cjs/loader.js:649:15)

  • Function.Module._resolveFilename - the name of the function that was being called. This may also be <anonymous> if the function did not have a name.
  • internal/modules/cjs/loader.js - the file containing the function.
  • 649 - the line that the function was called on.
  • 15 - the column on the line at which the function was called.

---

Stack trace pro-tip:

If the top of the stack trace points to a line of unfamiliar code, follow the trace down and see if you can find a file that you authored in it. It is likely that this function invocation will help you track down the bug.

---

Yellow Box: This contains the NPM Metadata associated with the bug. This will not always be present, NPM logged metadata here because NPM executed the script. It is unlikely that this data will be particularly helpful, but it will contain a filepath to a debug log that shows what NPM was doing in the background to execute this script.

In this error, the most straightforward data is the error message Error: Cannot find module '@babel/core'. The stack trace contains no familiar files, and the other parts of the error message don’t seem to be giving useful contextual info.

At this point, we can deduce that the error is related to Babel - the shell command in the green box is running babel, and the error message in the purple box relates to a missing babel module. A sensible course of action in this case would be to reference the babel docs, and ensure that we are using it correctly. A trip to the docs would tell us that an installation of @babel/core is required to use the babel-cli.

Let’s try adding @babel/core to our devDependencies!

Now, we’ll our compile script again…

Different error, yay!

It appears as though we have solved the original error, though when debugging, be mindful that an attempted fix MAY generate a new error, without solving the original error. It is up to you to discern whether this is the case or not. Always proceed with caution, and be informed as possible when attempting fixes!

Again, with this error, the stack trace isn’t pointing to any familiar files, but it is showing a similar error message: Error: Cannot find module '@babel/preset-react' from '/Users/johncastberg/code/hack-reactor/hrsf116/some-repo'

Maybe a similar fix will resolve this…

Now let’s attempt to run our script again:

Looks good...

Let’s double check to make sure the file actually transpiled:

Success Confimed!

Hooray, babel transpiled src/App.jsx -> public/App.js! Error is resolved!

Key takeaways:

• Take time to break down and read errors, they will almost certainly contain vital information that will help you fix bugs!
• Use the stack trace to identify the exact place in the code the error happened.
• Use the error message to get useful information about the error.
  • Keep in mind, you may not always get a useful error message, but you will always get a stack trace. Practice using both.

• Always check for errors when unexpected behavior happens, errors in client side code will appear in the Developer Tools console, errors in server side code will appear in the command line!

Happy Debugging!