这个不错

istanbul-middleware 的使用上 你们有遇到什么坑吗？ 我们这边使用这个， 在报告生成上是非常不准确的，因为他那块依赖的库都是好几年前的了，所以后面我们发现通过 nyc 的方式就可以解决这个事情的

不知道你会在什么情况下发生统计不准确呢？

我们在实践过程中发现，有俩坑：

1. 如果前端工程发布前做过代码混淆，那么覆盖率统计是不准确的，但未混淆代码的统计是基本准确的
2. 产品迭代过程中会产生代码的 commit 和 merge，并产生不同版本；但不同版本的覆盖率的累加难以相应 merge（或者说我们未能找到支持覆盖率 merge 的库）

同时感谢你的回复，我们调研一下 nyc。

感谢恒温大佬的支持

这个是我用 istanbul-middleware 生成报告的结果。
用的源码仓库是 https://github.com/vikpe/react-webpack-typescript-starter
然而 我再用 nyc 生成报告的话就是这样子

不知道你们有没有遇到过这种,所以我这边就直接弃用了 istanbul-middleware

说说我的理解：

• nyc 是新版 istanbul，解决了大量 istanbul 存在的问题
• nyc 和 istanbul 都用于【本地运行，本地统计覆盖率】的场景
• istanbul-middleware 是 istanbul 的一个 用于【多端运行，在服务端统计覆盖率总和】的场景

然后说说问题：
istanbul 有问题，一般报告和实际覆盖的行，往往有一两行偏差。我们对比过 coverage 和报告中的覆盖行数确实是一样的，因此我们怀疑 babel-plugin-Istanbul 太旧，如果工程用到较新的 babel/webpack 编译时，插桩可能就不太准确

如果我理解没错的话：

• 你贴的 Repo 似乎仅做了单元测试，属于【本地运行，本地统计覆盖率】的场景，这并不需要用到 middleware。升级 nyc 是没毛病的选择
• 但 nyc 未提供 middleware，对于【多端运行，在服务端统计覆盖率总和】的场景，我暂时没有什么好的解决方案

不知道我理解对不对，你有什么好想法我们可以接着讨论

请教一下，在使用 istanbul-middleware 时，用 nyc instrument 插桩，发现这种情况：
可以插桩成功

var App = React.createClass({
    render: function () {
        return (
            1
        )
    }
});

插桩失败

var App = React.createClass({
    render: function () {
        return (
            <View style={{ flex: 1, justifyContent: "center", alignItems: "center", flexDirection: 'column' }}>
            <Text>你好吃了吗11111？</Text>
        </View>
        )
    }
});

实在是找不到问题原因

你贴的 Repo 似乎仅做了单元测试，属于【本地运行，本地统计覆盖率】的场景，这并不需要用到 middleware。升级 nyc 是没毛病的选择
但 nyc 未提供 middleware，对于【多端运行，在服务端统计覆盖率总和】的场景，我暂时没有什么好的解决方案

其实我们这边目前的方案也是基本跟你上面的方案是一致的，只是说 istanbul-middleware 这块我们没有直接用它那个项目，因为这个项目归根到底就是一个 node 服务，然后调用了 istanbul 的 api 的。所以我们这边自己实现了一个 node 的服务，然后获取到 coverage 数据以后，通过 nyc 的 api 方式去生成了报告。不过目前这种方式还不能说完全没问题，因为我们现在刚把整个流程打通，还没有在业务项目里面真正的使用过。

请问一下，为什么我按照官方文档使用 nyc 绝对项目进行插桩，在服务运行过程中不能通过 window.coverage 查看覆盖率信息，但结束服务后能看到覆盖率报告呢，可能是哪些原因，求指点

1、使用 babel-plugin-Istanbul 插桩，和 babel-plugin-import 插件不兼容，导致编译失败
2、使用 nyc 插桩，插桩后 只能跟踪到编译后的源文件，且一个 7MB 的 js 文件插桩后变成 70 多 MB 了，对页面性能影响很大
这 2 个问题大家有遇到过吗

第一个我最近也遇到过，网上的解决措施是修改 import 源码，不过误打误撞发现 babelrc 里面增加插件 @babel/plugin-transform-modules-commonjs 可以解决。

第二个问题 没遇到 不过我觉的是不是你插桩的时候还插了第三库的代码才有这个问题

试了下，貌似没有效果

你能方面生成一个最小的项目出来不？一起探讨下 因为我们这边尝试好几个项目就是这么解决的

这边针对 2 个 github 的项目进行了测试：
1、https://github.com/duxianwei520/react 不成功，运行页面仍然提示 undefined

2、https://github.com/zuiidea/antd-admin 加上@babel/plugin-transform-modules-commonjs 插件后能插桩成功

项目 1 我这边是可以的。

原来是那个 commonJS 插件放的顺序的问题，@babel/plugin-transform-modules-commonjs 这个插件需要放在 import 插件前面才行，放在后面就会失败

请问下，你们有遇到过前端项目又依赖了自己开发的一些 sdk(js) 的情况吗？ 这种你们是怎么进行插桩的吗？感觉 node_modules 中的代码都已经是压缩编译后的，针对这些插桩没办法还原回来映射的源码的情况。

大佬，babel 自动编译插桩能详细解释下吗？只需要配置.babelrc 这个文件就可以吗

在我们的工程实践中，是的。但具体用法参考这个啦：https://github.com/istanbuljs/babel-plugin-istanbul

没有实践过，但我认为可以这么做：每个 SDK 独立插桩，独立调用接口上报覆盖率信息，独立维护 sourcemap 进行映射。依赖 SDK 的总工程，是没有办法帮助已编译的包插桩的

弱弱问一下，前端上报覆盖率信息的时候，repo 和版本信息是从哪里去获取的呢？ 大佬可以提示下么

大佬们，请教一个事，使用 Istanbul-middleware，/coverage 在线观看报告时，渲染有问题，报告是黑白的。调用接口/download 下载到本地之后，观看报告，宣传则是正常的，你们有遇到过吗？这是什么原因啊？

可以实现只查看特定分支与 master 的 diff 代码的覆盖率吗？

上报的数据你们是怎么存储的？

因为.vue 文件中也有 js，我想对.vue 文件插桩，今天看了下 nyc 的使用说明，有个--include 和--extension 开关，已经设置了

"nyc": {
  "extension": [
    ".js",
    ".vue"
  ],
  "include": [
    ".js",
    ".vue"
  ]
}

但插桩出来的结果为什么还只是.js 的，没有.vue 呢，我想问下楼主，nyc 支持.vue 吗，需要什么设置吗

你好，想请教一下，关于中间件 im 的接口 repo 是如何去设计的

你好，有个问题咨询下：前端代码和收集覆盖率的服务不在同一台机器，而且有两个 APP 同时测试，需要同时看这两个 APP 的覆盖率渲染页面。这种场景下怎么区分这两个 APPpost 的覆盖率数据那，楼主有相关的建议吗

请问有遇到过这样的问题吗？

这个你后来有方案了吗

您好，我这里碰见一个问题，能获取到报告的数据，但是没有样式

这个问题你后来解决了吗 我这里也遇到了

现在打包后上传的代码地址都是绝对路径，怎么改成打包后部署的代码路径（既查看代码覆盖率是部署后的代码）

这个你解决了吗？我也是这个问题，现在就像看到 部署后的源码，不想看本地的

解决了，路径问题

不是报告生成上是非常不准确的 而是插桩有问题

你好 ，我们公司是用 vite 打包的，请问下这个适用吗，如果不适用，有其他的替代品吗

感谢作者提供思路和干货，我封装了一系列的 istanbul 相关的库，若有需要的朋友可以看看：https://github.com/hemengke1997/istanbul-toolkit

可以使用的！