监控系统 配置sourceMap问题

什么是 Sourcemap

Sourcemap是一个信息文件，里面储存着代码转换前后的对应位置信息。它记录了转换压缩后的代码所对应的转换前的源代码位置，是源代码和生产代码的映射。Sourcemap主要解决在打包过程中，代码经过压缩、去空格以及babel编译转化后，由于代码之间差异性过大，造成无法debug的问题。 Sourcemap的作用是构建了处理前以及处理后的代码之间的一座桥梁，方便定位生产环境中出现bug的位置。因为现在的前端开发都是模块化、组件化的方式，在上线前对js和css文件进行合并压缩容易造成混淆。如果对这样的线上代码进行调试，肯定不切实际，sourcemap的作用就是能够让浏览器的调试面版将生成后的代码映射到源码文件当中，开发者可以在源码文件中debug，这样就会让程序员调试轻松、简单很多。

sourcemap文件提供了便利，但在生产环境，为了安全，建议关闭。因为通过.map文件和编译后代码可以很容易反编译出项目的源码，这样就相当于泄露了项目的代码。

sentry 配置SourceMap

在webpack.config.js配置 SentryWebpackPlugin插件

const SentryWebpackPlugin = require("@sentry/webpack-plugin");

module.exports = {
  // other configuration
  configureWebpack: {
    plugins: [
      new SentryWebpackPlugin({
        include: ".", 
        ignore: ["node_modules", "webpack.config.js"],
        configFile: "sentry.properties",
      }),
    ],
  },
};

include：指定路径让sentry-cli来检测有没有.map与.js文件，如果有就会上传到sentry。

sentry 有强大的金主爸爸们的支持，可以打包后把source-map 打包上传到静态资源服务器，这种方法需要额外配置服务器，的确是一种不错的方法，即解决了安全性也解决错误上报反编译源码的问题

方案二：

就是每次上产环境后，把对应产出的.map 文件需要上传到监控系统中，这个也是一种解决方案，但是唯一的问题就是，没次上生产环境都需要手动上传文件，对开发不够友好，比较麻烦，程序员怎么能容忍呢？还有其他方案吗？

方案三：

约定大于配置

约定大于配置”是一种常见的开发原则，意味着在开发过程中，通过约定和标准来减少不必要的配置。这个原则强调了在开发过程中，通过约定和最佳实践来减少配置的复杂性和冗余。“约定大于配置”的原则可以帮助开发团队减少不必要的沟通和协商，提高开发效率和代码质量

如果内部给.map 重新修改了一名称，在内部约定名称，监控系统根据约定去读取.map是不是会更简单点？基于这个思路我们通过约定的方式自定义一个规则，通过每次打包修改 生成的sourceMap 名称依旧可以保证生产环境的代码安全，而且只需要监控系统依照之前的约定方式解析sourceMap文件名称依旧可以实现解析，而且不需要在另外部署cdn,也不用是每次上线后手动上传sourceMap

为此我们写了一个修改打包后的依赖包 rename-source-map 生产打包的时候只需修改一下 生成的Sourcemap 文件即可

const webpackRenamePlugin=require('rename-source-map')
module.exports = defineConfig({
  transpileDependencies: true,
  productionSourceMap: true,
 
  configureWebpack: {
    //name: string 
    plugins: [new webpackRenamePlugin('_rename_')],
  },
})

生成文件名称的方式可以自定义一套规则生成，然后通过在监控系统和打包系统中引用即可，解决生产环境的下的反编译的问题。