In the past few weeks we’ve introduced you to some JavaScript frameworks. Now seems a suitable time to bring Source Maps to your attention! If you’ve ever found yourself wishing there was a hassle-free way to keep your clientside coding simple to debug and read after it’s been combined and minified, then Source Maps is here to make your life that much easier! Basically, this exists to map a combined/minified file back to an unbuilt state. Since Source Maps is still in its early days, it can benefit from your help! Think you could put it to good use? Do you think it’s worthy of further development?
JGB: I’m here with Michael Mifsud, who is a web developer at 99designs, and Michael is going to tell us all about Source Maps today. Can you start off by telling me what exactly are Source Maps? Michael: Source Maps are just a name for a way of mapping two equivalent files. If you have a file that has preprocessed or otherwise changed into another file, it’s able to map the outputted file to the source file. JGB: What do you use Source Maps for? Michael: The main use for it now is mapping minified JavaScript to the original source JavaScript. So you can always have the best performance production, have the ability and the context of your source files when you’re looking at them in a debugger. JGB: What problems does this solve exactly? Michael: Well, we all know that production code mysteriously breaks when it never breaks in development. Trying to debug 30,000 characters in a long single line JavaScript file is a nightmare. With Source Maps now you can dig into it and see what it looked like when you wrote it and have a bit of context. JGB: So why exactly would someone want to be able to live debug anyway? Michael: Well you can never control when things break. You’re often able to reproduce something in production that you can’t reproduce in development. So it gives you the ability to, in that moment, with the full context, figure out what’s gone wrong. JGB: So who can use Source Maps then and what skills do you need to have to use them? Michael: Essentially it’s for anybody who as part of their build process is minifying and concatenating files. Essentially you lose all context. It becomes one big jumble. So any kind of sizable web site will be doing this as a step. The concept of live debugging is for anybody. But doing it in a production environment is incredibly hard. If you have the Source Maps you’re able to see what you have created yourself. Creating the Source Maps itself is a bit of a chore. It’s to be done automated, it’s not something you’d generally do manually. So if you have a DevOps crew or some sort of deployment process it’d be part of that. JGB: So if Source Maps are so useful, why aren’t they currently being used? Michael: As with anything, it takes time. There’s infrastructure changes that need to made to automate the creating of Source Maps, and the software that generates them is few and far between. As with all the new HTML5 stuff it’s a living spec. It’s in the third version now and it often changes. So people aren’t willing to invest a lot of time into software that may change. But you can use third-party libraries. Right now it’s limited to Google’s closure compiler which is a Java library, and Java is not something that comes in a lot of modern web stacks or web development stacks. So it does take time and effort on the company’s behalf to get this into place. But there are people using it. It’ll grow as it gets more stable and easier to use. JGB: So what’s the future for Source Maps then? Michael: Well, right now, the main use is mapping minified JavaScript to normal JavaScript, because it’s a one-to-one mapping. Ideally in the future you’ll be able to map any preprocessed file from a CoffeeScript or SASS to the generated CSS or JavaScript. It’s a bit of a way off now, the issue there is that there is no longer a one-to-one mapping. In SASS you have things like mix-ins where there’s no longer direct line-to-line correlation, and there’s logic involved. It’s kind of the next step or next iteration of Source Maps.Frequently Asked Questions about Source Maps
What are the benefits of using source maps in web development?
Source maps are incredibly beneficial in web development. They allow developers to debug their code more efficiently by mapping the code within a compressed file back to its original position in the source file. This makes it easier to identify and fix errors, as the developer can see exactly where the problem lies in the original code. Source maps also help in improving the performance of a website as they allow for minification of code, which reduces the size of the file and speeds up the loading time.
How do I generate a source map?
Source maps can be generated in several ways. Many modern JavaScript transpilers, such as Babel and TypeScript, have built-in options for generating source maps. Additionally, build tools like Webpack and Rollup can also generate source maps. The process typically involves setting a specific option in the tool’s configuration file to enable source map generation.
How do I use a source map in Chrome DevTools?
To use a source map in Chrome DevTools, you first need to ensure that your source map is correctly linked in your minified JavaScript file. Once that’s done, open DevTools in Chrome by pressing F12 or Ctrl+Shift+I. Navigate to the ‘Sources’ tab, where you should see your original source files. You can then set breakpoints and debug your code as if you were working with the original, non-minified files.
Are source maps secure?
While source maps can expose your original source code, which could potentially be a security risk, there are ways to use them securely. One method is to only serve source maps to authenticated users, or to only use them in a development environment. Another option is to remove the comment that links to the source map from your minified files before deploying them to production.
Can I use source maps with CSS?
Yes, source maps can be used with CSS as well. They can be very helpful when working with preprocessed CSS languages like Sass or Less, as they allow you to see where an error is occurring in your original Sass or Less file, rather than in the generated CSS file.
How do source maps work with TypeScript?
When compiling TypeScript to JavaScript, you can generate a source map by setting the “sourceMap” option in your tsconfig.json file to true. This will create a .map file alongside your compiled JavaScript file. This map file can then be used by a debugger to map the JavaScript code back to the original TypeScript.
What is the structure of a source map file?
A source map file is a JSON object that contains information about the original source files and how they map to the minified code. It includes properties such as “version”, “sources”, “names”, “sourceRoot”, and “mappings”, each of which plays a crucial role in mapping the minified code back to its original source.
How do I view a source map?
Source maps can be viewed in the developer tools of most modern browsers. In Chrome, for example, you can view a source map by opening DevTools, navigating to the ‘Sources’ tab, and selecting the file you want to view. The mapped code will be displayed in the right-hand panel.
Can I use source maps in production?
While it’s technically possible to use source maps in a production environment, it’s generally not recommended due to potential security risks. However, if you need to debug a problem in production, you can temporarily enable source maps, or use a private symbol server to securely map minified code back to its original source.
What is the difference between inline and external source maps?
Inline source maps are included directly in the same file as the source code, encoded in a data URI. This can increase the size of the file, but ensures that the map is always available. External source maps, on the other hand, are separate files that are linked from the source code. This keeps the source file size smaller, but requires that the map file be available at the specified URL.
Jess Genevieve BrownJess is a video content creator for Learnable and Sitepoint. She digs all things social media, Web 2.0, music, film, digital media and innovation. Feel free get in touch!
