Nick Fitzgerald's Weblog

Hello, I'm Nick Fitzgerald. This is my weblog. You can also check out my shared items from Reader, moments on Twitter, and code on GitHub. Feel free to contact me about whatever.

Source Map Specification Discussion Mailing List

February 28th, 2013

If you are interested in discussing the source map specification and any future modifications to it, please join us on the new dev-js-sourcemap mailing list. The Google Groups archive hasn't synced yet, but I am told that it should be synced within a week.

This list exists only for discussing the source map specification, not any of the various tools which use source maps. They each have their own preferred mediums of communication which you should use for tool specific discussions.

Regarding "Dynamic Source Maps"

January 22nd, 2013

Peter van der Zee recently wrote about source maps; in particular, he detailed the ways that he has found them lacking and proposes changes to the source map spec that he believes would improve them to support his use cases.

What Peter wants is to generate and consume source maps at runtime in the browser, and develop without an extra compilation and refresh step. When you are editing and compiling sources inside of the browser, rather than sources on a file server, you can't point to a remote URL where the original source (the source before the compilation step) is located. This is problematic because source URLs are exactly what source maps require, as defined by the spec.

Peter then outlines proposed changes to the source map spec to support his need for "dynamic" source maps. First, adding a new comment pragma //@ sourceMapping=<source map JSON blob>. Second, to include the full original source(s) inside the source map rather than including URLs pointing to the location of the original source(s).

Peter is a very intelligent person, and I have been following his blog for more than two years (you should follow, too), but I believe that he jumped the gun by leaping from his use cases to proposing changes to the source map spec. The one doesn't lead to the other because his use case is already supported by the current specification as-is.

How? Data URLs. Encode the original source(s) as data URLs in the source map's sources list, and encode the whole source map as a data URL in the //@ sourceMappingURL comment pragma appended to the generated source. By doing this, both the whole source map and complete original source(s) are attached directly to the generated source. This accomplishes the same goals that Peter's solution does: you can dynamically generate source maps inside your browser environment (presumably with the mozilla/source-map library) and all of the resources can exist inside your development environment instead of on a remote server.

The benefits to using data URLs are:

No changes to the source map spec. No waiting on debates, or for the spec authors to come to an agreement. Furthermore, existing tooling around source maps will continue to work, including integration with browsers' built in debuggers.
No need for yet another comment pragma. We already have //@ sourceMappingURL, //@ sourceURL, and //@line. Some are only supported by some tools, and some browsers; only one is part of a standard; two either are or should be deprecated. This is confusing enough already, and once we add another comment pragma it will be there forever.
It is optional to include the full text of the original source(s) in the source map. Developers who are using a more "traditional" development cycle will not be negatively affected by having a larger source map to download.
Encoding and decoding data URLs is simple. Browser environments already have window.btoa and window.atob to encode and decode base 64 respectively, which makes integration with whatever tooling you are using that much easier.

If I have overlooked any facet of Peter's use cases that isn't supported by using data URLs, I would love to know in the comments.

Update on Firefox and Source Maps

July 30th, 2012

This is a quick update on the status of Firefox's support for source maps.

The library for parsing and generating source maps has landed in Nightly! If you want to write an addon which either uses or creates source maps, import the source map module with Components.utils.import("resource:///modules/devtools/SourceMap.jsm"). The documentation for the source map module is on GitHub. The history is inside bug 669999.

What I am working on now is writing the plumbing between our script loaders, SpiderMonkey, and the debugger API to shepherd the source map URL for a given script to our developer tools. I have working patches for most of this, it is "just" a matter of writing test cases, getting proper review, updating patches based on review feedback, and constantly rebasing dependent patches on top of said updates.

You can follow along with the plumbing in these bugs:

Once that plumbing is complete, adding source map support to the debugger's UI should be pretty straight forward since all the required data will already be available. You can follow along with that final piece on bug 771597: Integrate source maps with the debugger.

Source Code Cartography

December 23rd, 2011

I spent the summer at Mozilla working on source maps. Source maps allow one to map the line and column information between an original source and a generated source for debugging purposes. Watch the webcast to learn more!

Pycco Needs a Loving Home

August 17th, 2011

When I wrote Pycco, it was meant to be a single-serving coding session. It was fun and simple. But then the project started receiving more attention than I ever expected it to. In fact, one year later, I am still getting a pull request every month or so. But the problem is that I no longer have the time to spend nor interest in maintaining the project. I feel bad because a few people are out there dedicating their own precious time while writing code to make Pycco better, and I'm not holding up my end of the bargain by reviewing that code and merging it back to the project.

If anyone would like to adopt this project and give it a loving home, please leave a comment here and we can work it out. I'd hate to see the project rot away while there are definitely still a few people interested in it.

« Older Entries

Source Map Specification Discussion Mailing List

Regarding "Dynamic Source Maps"

Update on Firefox and Source Maps

Source Code Cartography

Pycco Needs a Loving Home

Recent Entries