mac文件损坏解决方法_您的源地图已损坏。 这是解决方法

mac文件损坏解决方法

Source maps are awesome. Why? Because they are used to display your original JavaScript while debugging, which is a lot easier to look at than minified production code. In a sense, source maps are the decoder ring to your secret (minified) code.

源地图很棒。 为什么？ 因为它们用于在调试时显示原始JavaScript，所以比最小化的生产代码要容易得多。 从某种意义上说，源映射是通往您的秘密（最小化）代码的解码器。

However, they can be tricky to get working properly. If you’ve run into some trouble, the tips below will hopefully help you get everything in working order.

但是，他们可能很难正常工作。 如果遇到麻烦，下面的提示将有望帮助您使一切正常。

If you’re looking to get started with source maps for the first time, check out our earlier post, _Debugging Minified JavaScript with Source Maps, before continuing._

如果您希望第一次开始使用源地图，请先阅读我们较早的文章_ 使用源地图调试Minified JavaScript ，然后再继续。

缺少或不正确的源映射指令 ( Missing or incorrect source map directive )

We’re going to presume that you’ve already produced a source map using a tool like UglifyJS or Webpack. But generating a source map isn’t worth diddly if the browser can’t find it. To do that, browser agents expect your bundled JavaScript files to contain either a sourceMappingURL comment or return a SourceMap HTTP header that points to the location of the source map.

我们假设您已经使用UglifyJS或Webpack之类的工具生成了源地图。 但是，如果浏览器找不到源代码图，则不值得花很多功夫。 为此，浏览器代理希望您绑定JavaScript文件包含sourceMappingURL注释或返回一个SourceMap HTTP标头，该标头指向源地图的位置。

To verify your source map directive is present and working, you need to:

要验证您的源映射指令存在并且可以正常工作，您需要：

Locate the sourceMappingURL comment at the very end of the file on its own line:

在文件的最后 sourceMappingURL 找到 sourceMappingURL 注释：

//# sourceMappingURL=script.min.js.map

This value must be a valid URI. If it is a relative URL, it is relative to the path location of the bundled JavaScript file (e.g., script.min.js). Most source map generation tools generate this value automatically for you, but also provide an option for overriding it.

该值必须是有效的URI。 如果它是相对URL，则它相对于捆绑JavaScript文件的路径位置（例如script.min.js ）。 大多数源地图生成工具会自动为您生成此值，但也提供覆盖它的选项。

Using UglifyJS, you can generate this comment by defining url=script.min.js.map in your source map options:

使用UglifyJS，您可以通过在源映射选项中定义url=script.min.js.map来生成此注释：

# Using UglifyJS 3.3
$ uglifyjs --source-map url=script.min.js.map,includeSources \
  --output script.min.js script.js

Using Webpack, specifying devtool: "source-map" in your Webpack config will enable source maps, and Webpack will output a sourceMappingURL directive in your final, minified file. You can customize the source map filename itself by specifying sourceMapFilename.

使用Webpack，在Webpack配置中指定devtool: "source-map"将启用源映射，并且Webpack将在最终的sourceMappingURL文件中输出sourceMappingURL指令。 您可以通过指定sourceMapFilename定义源地图文件名本身。

// webpack.config.js
module.exports = {
    // ...
    entry: {
      "app": "src/app.js"
    },
    output: {
      path: path.join(__dirname, 'dist'),
      filename: "[name].js",
      sourceMapFilename: "[name].js.map"
    },
    devtool: "source-map"
    // ...
};

Note that even if you generate sourceMappingURL properly, it’s possible that it isn’t appearing once you serve your final version in production. For example, another tool at the end of front-end build toolchain might be stripping comments — which would have the effect of removing //# sourceMappingURL.

请注意，即使您正确生成了sourceMappingURL ，也可能一旦在生产中提供最终版本sourceMappingURL不会出现。 例如，前端构建工具链末尾的另一个工具可能是删除注释—这将删除//# sourceMappingURL 。

Or your CDN might be doing something clever like stripping comments unknowingly; Cloudflare’s Autominify feature has stripped these comments in the past. Double-check your file in production to make sure your comment is there!

或者您的CDN可能正在做一些聪明的事情，例如不知不觉地删除评论； Cloudflare的Autominify功能过去已经删除了这些注释。 在生产环境中仔细检查您的文件，以确保您的评论在那里！

Alternatively: Ensure your server returns a valid SourceMap HTTP header

或者：确保您的服务器返回有效的SourceMap HTTP标头

Instead of this magic sourceMappingURL comment, you can alternatively indicate the location of the source map by returning a SourceMap HTTP header value when requesting your minified file.

代替此神奇的sourceMappingURL注释，您还可以通过在请求缩小文件时返回SourceMap HTTP标头值来指示源地图的位置。

SourceMap: /path/to/script.min.js.map

Just like sourceMappingURL, if this value is a relative path, it is relative to the path location of the bundled JavaScript file. Browser agents interpret the SourceMap HTTP header and sourceMappingURL identically.

就像sourceMappingURL一样，如果此值是相对路径，则相对于捆绑JavaScript文件的路径位置。 浏览器代理对SourceMap HTTP标头和sourceMappingURL解释相同。

Note that to serve this header, you need to configure your web server or CDN to do so. Many JavaScript developers may not have the capability of setting arbitrary headers on their static assets in production, so for most, it's easier to just generate and use sourceMappingURL.

请注意，要提供此标头，您需要配置您的Web服务器或CDN。 许多JavaScript开发人员可能没有能力在生产中的静态资产上设置任意标头，因此对于大多数情况而言，仅生成和使用sourceMappingURL更容易。

缺少原始源文件 ( Missing original source files )

Let’s assume that you’ve properly generated your source map, and your sourceMappingURL (or SourceMap header) is present and correct. Parts of the transformation are clearly working; for example, error stack traces now mention your original filenames and contain sensible line and column locations. But despite this improvement, there’s a big piece missing — you still can’t browse your original source files using your browser’s debug tools.

假设您已经正确生成了源地图，并且您的sourceMappingURL （或SourceMap标头）存在且正确。 转型的某些部分显然正在发挥作用； 例如，错误堆栈跟踪现在提到您的原始文件名，并且包含明智的行和列位置。 但是，尽管有了这一改进，但是仍然遗漏了一大片-您仍然无法使用浏览器的调试工具浏览原始源文件。

This likely means that your source map doesn’t contain or link to your original source files. Without your original source files, you’re still stuck stepping through minified code in your debugger. Ouch.

这可能意味着您的源地图不包含或链接到原始源文件。 如果没有原始的源文件，您仍然会陷入调试器中缩小代码的过程。 哎哟。

There are a handful of solutions for making your original source files available:

有一些使原始源文件可用的解决方案：

Inline your original source code into your source map via **sourcesContent**

通过** sourcesContent ** 将原始源代码内嵌到源地图中

It’s possible to inline your entire original source code into the source map itself. Inside the source map, this is referred to as sourcesContent. This can make for really large source map files (on the order of megabytes) but has the advantage of being really simple for browser agents to locate and link up all your original source files. If you’re struggling to get your browser to find your original sources, we recommend trying this.

可以将整个原始源代码内联到源映射本身中。 在源映射中，这称为sourcesContent 。 这可以生成非常大的源映射文件（兆字节数量级），但优点是浏览器代理可以非常简单地找到并链接所有原始源文件。 如果您想让浏览器查找原始资源，我们建议您尝试一下。

If you’re using UglifyJS, you can inline your original source code into your source map’s sourcesContent property using the includeSources CLI option:

如果您使用的是UglifyJS，则可以使用includeSources CLI选项将原始源代码内联到源映射的sourcesContent属性中：

uglifyjs --source-map url=script.min.js.map,includeSources --output script.min.js script.js

If you’re using Webpack, there’s nothing to do here — Webpack inlines your original source code into your source maps by default (assuming devtool:"source-map" is enabled).

如果您使用的是Webpack，则无需执行任何操作-默认情况下，Webpack将原始源代码内联到源映射中（假定devtool:"source-map"已启用）。

Host your original source files and serve them publicly

托管原始源文件并公开提供

Instead of inlining your original source files, you can instead host them on your web server such that they can be individually downloaded by browser agents. If you’re concerned about security — these are your original source files, after all — you can serve the files via localhost or make sure they’re protected behind a VPN (e.g., the files are only reachable via your company’s internal network).

不必内联原始源文件，您可以将它们托管在Web服务器上，以便浏览器代理可以单独下载它们。 如果您担心安全性-毕竟这是您的原始源文件-您可以通过localhost提供文件或确保它们在VPN后面受到保护（例如，文件只能通过公司的内部网络访问）。

Sentry users only: upload your source files as artifacts

仅哨兵用户：将您的源文件作为工件上传

If you’re a Sentry user and your primary goal is making sure source maps are available so that Sentry can unminify your stack traces and provide surrounding source code, you have a third option: upload your source files as artifacts using sentry-cli or directly via our API.

如果您是Sentry用户，并且首要目标是确保源映射可用，以便Sentry可以最小化堆栈跟踪并提供周围的源代码，那么您还有第三种选择：使用sentry-cli或直接将源文件作为工件上传通过我们的API。

Of course, if you do either of the first two options — either inlining your original files or hosting them publicly — Sentry will find the content that way too. It’s your call.

当然，如果您执行前两个选项中的任何一个（内联原始文件或公开托管它们），Sentry也会以这种方式找到内容。 是你的电话

由多次转换引起的不良源地图 ( Bad source maps caused by multiple transformations )

If you’re using two or more JavaScript compilers invoked separately (e.g., Babel + UglifyJS), it’s possible to produce a source map that points to an intermediate transformed state of your code, rather than the original source code. This means that when you debug in the browser, the code you’re stepping through isn’t minified — an improvement for sure — but it’s still not a 1:1 match with your original source code.

如果您使用的是两个或两个以上分别调用的JavaScript编译器 （例如Babel + UglifyJS），则可能会生成指向您代码的中间转换状态的源映射，而不是原始源代码。 这意味着，当您在浏览器中进行调试时，您要逐步执行的代码不会被缩小（可以肯定会有所改进），但是仍然与原始源代码不是1：1匹配。

For example, let’s say you used Babel to convert your ES2018 code to ES2015, then ran the output through UglifyJS:

例如，假设您使用Babel将ES2018代码转换为ES2015，然后通过UglifyJS运行输出：

# Using Babel 7.1 and UglifyJS 3.3
$ babel-cli script.js --presets=@babel/env | uglifyjs -o script.min.js \
  --source-map "filename=app.min.js.map"
$ ls script*
script.js script.min.js script.min.js.map

If you were to use the source map generated by this command, you’ll notice it won’t be accurate. That’s because the source map only converts from the minified (Uglified) code back to the code generated by Babel. It does not point back to your original source code.

如果要使用此命令生成的源地图，您会发现它不准确。 这是因为源映射仅从缩小的（Uglified）代码转换回由Babel生成的代码。 它不会指向您的原始源代码。

Note this is also common if you’re using a task manager like Gulp or Grunt.

请注意，如果您正在使用任务管理器（例如Gulp或Grunt），这也很常见。

To fix this, there are two possible solutions:

要解决此问题，有两种可能的解决方案：

Use a bundler like Webpack to manage all your transformations

使用Webpack等捆绑程序来管理所有转换

Instead of using Babel or UglifyJS separately, use them instead as Webpack plugins (e.g., babel-loader and uglifyjs-webpack-plugin). Webpack will produce a single source map that transforms from the final result back to your original source code, even though there are multiple transformations taking place under the hood.

与其单独使用Babel或UglifyJS，不如将它们用作Webpack插件（例如babel-loader和uglifyjs-webpack-plugin ）。 Webpack会生成一个源映射，即使在后台进行了多次转换，该源映射也可以从最终结果转换回原始源代码。

Use a library to “stitch” together source maps between transformations

使用库在转换之间将源图“缝合”在一起

If you’re committed to using multiple compilers separately, you can use a library like source-map-merger, or the source-map-loader Webpack plugin, to feed the results of an earlier source map into a subsequent transformation.

如果您承诺分别使用多个编译器，则可以使用诸如source-map-merger或source-map-loader Webpack插件之类的库将早期源映射的结果提供给后续转换。

If you have a choice in the matter, we’d recommend pursuing the first option — just use Webpack and save yourself some grief.

如果您在此问题上有选择，我们建议您采用第一种方法-只需使用Webpack并为自己省些麻烦。

文件版本错误或缺少版本 ( Files are incorrectly versioned or missing versions )

Let’s say you’ve followed all of the above. Your sourceMappingURL (or SourceMap HTTP header) is present and properly declared. Your source maps include your original source files (or they’re publicly accessible). And you’re using Webpack end-to-end to manage your transformations. And yet, your source maps still periodically create mappings that don’t match.

假设您已遵循上述所有条件。 您的sourceMappingURL （或SourceMap HTTP标头）已存在并正确声明。 您的源地图包括您的原始源文件（或可以公开访问）。 您正在使用Webpack端到端管理您的转换。 但是，您的源映射仍然会定期创建不匹配的映射。

There’s a remaining possibility: bad transforms caused by mismatched compiled files and source maps.

还有一种可能性：由不匹配的编译文件和源映射导致的不良转换。

This happens when a browser or tool downloads a compiled file (e.g., script.min.js), then attempts to fetch its corresponding source map (script.min.js.map), but the source map it downloads is “newer” and corresponds to a different version of that compiled file.

当浏览器或工具下载已编译的文件（例如script.min.js ），然后尝试获取其对应的源映射（ script.min.js.map ），但下载的源映射是“较新的”时，会发生这种情况对应于该编译文件的其他版本。

This situation is uncommon but can occur if a deploy is triggered while you’re debugging, or you’re debugging using browser-cached assets that are about to expire.

这种情况很少见，但是如果在调试时触发了部署，或者使用即将到期的浏览器缓存资产进行调试，则会发生这种情况。

To solve this, you need to version your files and your source maps, either by:

要解决此问题，您需要通过以下方式对文件和源地图进行版本控制 ：

• Versioning each filename, e.g., script.abc123.min.js
  版本化每个文件名，例如script.abc123.min.js
• Versioning the URL’s query string, e.g., script.min.js?abc123
  对URL的查询字符串进行版本控制，例如script.min.js?abc123
• Versioning a parent folder, e.g., abc123/script.min.js
  对父文件夹进行版本控制，例如abc123/script.min.js

Whichever you strategy you choose doesn’t matter, only that you use it consistently for all your JavaScript assets. It’s expected that each compiled file → source map share the same version and version scheme, like the following example:

无论选择哪种策略都没有关系，只需要对所有JavaScript资产一致地使用它即可。 期望每个编译文件→源映射共享相同的版本和版本方案，如以下示例所示：

// script.abc123.min.js
for(var a=[i=0];++i<20;a[i]=i);
//# sourceMappingURL=script.abc123.min.js.map

Versioning this way will ensure that each browser agent downloads the source map that belongs to each compiled file, avoiding version mismatches.

通过这种方式进行版本控制将确保每个浏览器代理下载属于每个已编译文件的源映射，从而避免版本不匹配。

If you’ve read this far, you should be fairly equipped to fix source map transformations and debug like a pro. Nice work. Think of something we missed? We look forward to your email.

如果您已读过本文，那么您应该有足够的能力修复源映射转换并像专家一样进行调试。 辛苦了 想起我们错过的东西吗？ 我们期待着您的来信 。

We also highly recommend checking out the Sentry documentation on this topic.

我们也强烈建议您查看有关此主题的Sentry文档 。

翻译自: https://scotch.io/tutorials/your-source-maps-are-broken-heres-how-to-fix-them

mac文件损坏解决方法