[Help] v8数据生成istanbul报告，建议将statement换成行统计数据

[fanksy]

v8数据转换的istanbul报告里面，一个statement包含整个方法，精确性太低，通常istanbul将每行视为一个语句，希望将statement数据替换成v8报告里面的行数据

[cenfun]

statement如果换成line那岂不是和line一样，就失去了意义 statement是一个最小的执行语句，比如var x= 10; console.log(x); 写在同一行，那么计成1行，但有2个statements 也许多数情况下statement和line相等，但概念不同 这里的statements是按照AST定义里面的Statements来统计的，可能比Istanbul的更精确，除非是sourcemap的问题没有得到还原，可以把你的实际情况发出来看看

[fanksy]

report.zip

statement确实有问题，范围很大，甚至包含好几个方法，附件有完整报告和数据

[fanksy]

里面的方法名能否用sourcemap还原，v8-to-istanbul是可以做到的

[cenfun]

试试build的时候不要minify，跑测试无需minify，用开发模式，有treeShaking也关闭，尽量保留原始代码结构和内容，这样才能尽可能用sourcemap还原，见 常用工具设置

v8-to-istanbul本身逻辑就是用一行作为一个statement，因为它不支持解析AST结构，就是从简这样做，自然就会出现一行有多个statements的问题。没有问题可能是源代码刚刚巧合正好statement和line一样

而且v8-to-istanbul的functions和branches也都是错的，行其实也有错误，它不支持空行和注释行筛除。 这些问题之前都和它的maintainer讨论过，但他们不会解决，而且希望我将新的转换贡献过去，但这个改动对v8-to-istanbul影响太大，不容易实现，而且我更倾向于直接使用V8的报告，不太想用Istanbul的方式，因为除了想使用一下lcov报告，其实没有必要转换成Istanbul。

[fanksy]

其实我也试过不开启minify，但一样有问题。如果不开启压缩，那么上线前就必须再次压缩重新打包，这样会破坏devops始终基于同一个交付的原则。可能对纯js支持会好点，jsx、tsx这种不行。

可以考虑先把方法名称还原，转成istanbul只是为了方便与其他系统集成，方法名是混淆的，这样不利于其他系统解析集成

[cenfun]

你说的方法名还原具体指的是啥？ 因为minify后，方法名都变成缩减的名称，你指的是这里要还原？不仅仅如此，minify后很多原来的位置是无法找到的，有很多问题

一般不应该只打生产包的，测试阶段用测试包，开发模式，不压缩，便于调试，等测试全部通过，最后上线再打生产包，也不麻烦，用环境变量区分即可

[cenfun]

比如，我们一般有dev，qa，stg，live这些环境，但可能小公司起码也有dev和live两个环境吧

• dev的devops有全面测试环节，顺便会生产覆盖率报告，单元测试，UI自动化测试，手动测试，开发调试等在这个环境做完
• live的devops就应该没有生成覆盖率这个环节了，甚至也应该不生成map文件，只是做smoke测试

感觉你的情况就是直接用live的一个devops就想完成所有事情，应该很多问题，理论上没法实现

[fanksy]

比如，我们一般有dev，qa，stg，live这些环境，但可能小公司起码也有dev和live两个环境吧

• dev的devops有全面测试环节，顺便会生产覆盖率报告，单元测试，UI自动化测试，手动测试，开发调试等在这个环境做完
• live的devops就应该没有生成覆盖率这个环节了，甚至也应该不生成map文件，只是做smoke测试

感觉你的情况就是直接用live的一个devops就想完成所有事情，应该很多问题，理论上没法实现

目前是打了一个完整的大包，通过网关屏蔽文件，屏蔽规则根据环境来适配，比如测试环境就允许访问map，生成环境被屏蔽掉了

[cenfun]

其他都还好，但这个对收集覆盖率来说恐怕难以实现，v8起码还能对runtime的代码收集，即使minify也行，只是不准确 但如果直接使用Istanbul就完全不行，它需要把计数器的代码build进源代码才行，包的体积一般大一倍以上

至于minify的代码如何用sourcemap精确还原，这个的确我已经进了最大努力，连diff算法都用上了，但还是很难的 因为minify后的代码和源代码可以没有任何联系，尤其react，vue这些

所以看不能试试改下流程，使用开发模式收集覆盖率