source map被标准化
2023年7月份的“TC39”全员会议期间，一个新的任务组（TC39-TG4）被组建出来用于从事“source map”的标准化工作。其实十几年前“source map”的第一版从事协议制定和开发的人员就公开提议将他们的spec交给“TC39”，使其成为正式的标准，但是没想到直到十几年之后的今年才实现。
source map的来龙去脉
2001年的时候JavaScript的初步压缩功能就问世了。2007年压缩工具“YUI Compressor”问世。使用压缩工具可以提高Javascript在网络上的传输效率，但是压缩后的代码调试起来非常痛苦，因为压缩后的代码基本上只有一行。这个情况直到2009年谷歌的“Closure”编译器中带了一个新功能，就是“source map”，翻译成中文就是“源代码映射”，解决了调试难的问题。后来“UglifyJS2”也支持了“source map”。“source mapp”虽然是谷歌开发的初始版本，但是后来众多工具和框架都开始支持“source map”，众多社区开发者、机构参与了spec的制定和实现工具的开发，当前spec的地址是这里。
“source map”其实早就是JavaScript生态系统的一部分了，所有的主流浏览器、构建和调试工具 都支持“source map”。有了“source map”，压缩或者转化处理后的代码和原始代码间就有了对应关系，从而开发人员就可以像调试源代码一样调试处理后的代码。
为什么需要标准
然而“source map”十几年以来一直是只有spec，但是没有正式的标准。 下面两个主要原因促使相关开发人员提议将“source map”提交给“TC39”，以便制定正式的标准：
- spec文档里里有很多模棱两可的描述。这导致各个工具按照自己的理解实现，从而导致不一致。
- 现在的"source map"在性能和信息表达方面存在不足，导致各个公司开发了自己的第三方的补丁来弥补这些不足。长此以往，只会越来越乱。所谓信息表达方面的不足，举一个例子：在显示错误堆栈时，“source map”可以指出具体错误在源代码中的位置，但是函数却不能还原成原函数的名称。
标准得到了大家的拥护
提交到“TC39”制定正式标准这个决议得到了所有重要“source map”工具实现机构的支持（微软、谷歌。。。）。
“TC39”还没有完全想好该怎么让这个工作组较好的运作，但是总算是开始了。
到此结束。
