 Hello, my name is Benjamin Coe. I'm excited to be here today at OpenJS World. Today I'm going to be giving a lightning talk entitled Everything You Didn't Want to Know About Source Maps. It talks about source maps, the modern JavaScript ecosystem, and relates these topics to the Node.js project, which I contribute to. So, a little bit about me. I'm originally from a small town near Toronto named Fergus. I've been in California for the last eight years, though. I was an early employee at MPM, which is where I started to get really interested in open source JavaScript. I'm a collaborator on Node.js, where I do a lot of work around tooling and help run the tooling group, and I'm a developer programs engineer at Google. This involves a little bit of DevRel and a little bit of engineering. So, to give you an idea of what we're going to be talking about for the rest of this presentation, I'm going to go a little bit into what exactly source maps are and how you probably might already be using them. I'm going to talk about why I think it's been important to build out features around source maps in Node.js. And finally, I'm going to show how you can start to use these features today. The 2019 State of JS survey indicated a really interesting statistic, which is that about 60% of engineers when working with JavaScript use some flavor other than vanilla, so that that might be TypeScript, that might be JSX as an example. So, to put that another way, a lot of engineers are writing code that looks something like this. Note the interface in this TypeScript program. But once the code is actually run inside an interpreter, such as V8 and Node.js, it actually looks fairly different because the code has been compiled down to vanilla JavaScript. Let me give you a real-world example. The slides for this talk itself were implemented in TypeScript, and there's an exception in the next slide. Let's move forward one slide and see what happens. Okay, so what we have here is a stack trace. And what I want to note is the top line indicates that the exception in our talk happened on line 195 of presentation.js. What's confusing about this is there is no presentation.js. There's a presentation.ts. And furthermore, there's no error on line 195. It's all the way down at line 213. So what happened to us here? Well, the problem is that Node.js and V8 don't see the original code. They see the compiled code that TypeScript was compiled down to. Fortunately, there's a specification called source map V3, which describes met information that can be added to files and help map from the compiled code back to the original. Most common JavaScript compilers like TypeScript already insert these source maps at the bottom of your files. And as of recently, this format is now supported by Node.js. So how exactly do you use this? When running Node.js, you can now pass the enable source map flag. What this does is it indicates to Node that it should start collecting this source map met information it sees in files, which it can then use to give you stack traces that include both the original file and the compiled file when an exception occurs. You can set this option in a variety of ways. I like to use the node options flag if I'm trying to pass it to MPM as an example. If you happen to be using mocha, one option is to set it in the mocha configuration file. So let's revisit that exception that happened earlier in this presentation. TypeScript inserts source maps in the bottom of the compiled files. This happens automatically. If I were to run my presentation with the node option enable source map set, we can then go back to that exception that occurred and see how the stack trace looks different. So let's look at this new stack trace. It still includes the compiled presentation.js and tells you what line the error happened on, but it also includes the actual presentation.ts, which is the file I'm working in, and it now points to the correct line 213. Let's take a look. Sure enough, 213 is where that error is actually being thrown. So if you're working in something like TypeScript that compiles to JavaScript, I encourage you to try out Node's new enable source map flag. It's my hope that it helps you better reason about errors in your applications. I would love for you to give me feedback on the Node.js project or to reach out to me personally. Thank you for the opportunity to speak today. If you do want to reach out to me with feedback or for any reason, my DMs are open on Twitter. I wrote a blog post about the experience of adding source map support to Node.js. Which you can find in this link here. And if you're curious about the specification, source map v3, you can find it on source maps.info. Finally, I'd like to thank Joel Lord for the slide framework I used in this talk today. It's really cool.