Pass opts to BabelPluginIstanbul options #1
Comments
|
Spoke too soon; while this does instrument the I'm in a bit over my head with this, but I'll keep trying to figure this out and will post what I find here. UpdateWhen programmatically instrumenting code with In Vite, the SFC compilation happens immediately before the Unfortunately, that map is not provided in the context to our const result = await t.transform({
...transformContext,
code,
map: ctx.map, // added
})then we could simply pass that to the babel plugin, like: plugins: [[BabelPluginIstanbul, { ...opts, inputSourceMap: ctx.map }]],Indeed, this works for me locally when I add that to the file in my |
|
Hi, yes i intend to keep maintaining this as i depend on it in other projects i have, however i have only tested it with JS and not any custom transforms like JSX or Vue's SFC. I only have time on the weekends to go on GitHub and to spend time on my projects, which is why i only saw the issue now. I'll look into the issue and get back when i have a solution, i'll fork your project to be able to reproduce the bug. However as you said the issue of slotting in the custom sourceMap should maybe be handled on Vite's end. Great detective work btw 😀👍, i'll look into this tomorrow and probably we can work out a solution that works best for Vue. |
|
Hey appreciate the response! Yeah no worries of course, I checked in in case you had any quick ideas, but no need to dig too hard. I may actually make a PR to Vite to see if they'll pass the map to |
|
@michaelhays Hey, it seems that there is now a way to get the source map in the Vite 2.0 beta, it seems that there is an added method called getCombinedSourcemap that generates the current source map from all the previous transforms. I'll adjust the plugin and should have a patch up in the weekend to add the feature. Then maybe you could verify if it works in your project (if you haven't already fixed it some other way). |
|
Hey thanks so much for the help. I'd tried some things with the map in the Vite 2.0 beta, but hadn't seen I ended up going with this: import istanbulInstrument from 'istanbul-lib-instrument'
import { createFilter } from '@rollup/pluginutils'
export default function istanbul(options) {
const filter = createFilter(options.include, options.exclude)
return {
name: 'istanbul',
transform(src, id) {
if (
process.env.NODE_ENV == 'production' ||
id.startsWith('/@modules/') ||
id.includes('node_modules') ||
!filter(id)
) {
return
}
let scriptSrc = src
let scriptStartIndex
let scriptEndIndex
if (id.endsWith('.vue')) {
scriptStartIndex = src.indexOf('<script>')
scriptEndIndex = src.indexOf('</script>')
if (scriptStartIndex === -1 || scriptEndIndex === -1) {
return
}
scriptStartIndex += '<script>'.length
const numNewlines = (src.slice(0, scriptStartIndex).match(/\n/g) || [])
.length
scriptSrc =
'\n'.repeat(numNewlines) + src.slice(scriptStartIndex, scriptEndIndex)
}
const instrumenter = new istanbulInstrument.createInstrumenter({
esModules: true,
compact: true,
produceSourceMap: true,
autoWrap: true,
preserveComments: true,
})
let code = instrumenter.instrumentSync(scriptSrc, id)
if (id.endsWith('.vue')) {
code =
src.slice(0, scriptStartIndex) +
'\n' +
code +
'\n' +
src.slice(scriptEndIndex)
}
return code
},
}
}This plugin runs before the Vue plugin. Basically, for So don't feel any obligation to patch this, unless you'd like to offer the functionality as part of the plugin. I know it's basically just you and me right now, but hopefully more people start using this as Vite matures. If you do add it, I'm happy to test out any changes you make with my codebase. |
|
No I'll fix it because I need to update the package anyways to fit the new plugin spec. I'll work on a patch this weekend. I'll report back when it's done so you can check if it works. |
|
@michaelhays Hey again, version 2.x of the plugin is now compatible with Vite 2.0, also added the aforementioned patch with the source maps. Could you please verify if it seems to work well with the coverage in your project? |
|
A few issues I'm having:
Error I was getting: I fixed this by changing this line to
I have to change that return to this in order to get this working: Not sure if this is a bug with Vite, or if there's something else I'm missing. Unfortunately, even when I make all of these changes in |
|
Weird, i'll get back to this in a week or so and see if i can add the fix you provided earlier, maybe do the fix only if the id contains a .vue extension. Thanks for describing the other bugs with the SourceMap too. |
|
It looks like this plugin is still not working. I tried to get Cypress to work with it for three days, but to no avail. |
|
Thanks for reminding me, I've taken an unplanned break from coding in my freetime. But I will look into @michaelhays solution again and see if I can integrate something based on that. I remember not doing it before because I thought there was a better solution. But solution is in fact better than no solution after all 😊. However I will push out an update today or tomorrow. |
|
Glad it was helpful @sdvinfo! :) A couple of other things that I've done since then that might help: the plugin doesn't generate a source map, so the files loaded in the browser will contain the instrumented code. This can make debugging difficult, so I added an environment variable to only instrument the code when running Cypress tests. In import istanbul from './vite-plugin-istanbul'
import vue from '@vitejs/plugin-vue'
/**
* @type {import('vite').UserConfig}
*/
const config = {
plugins: [vue()],
}
if (process.env.VITE_INSTRUMENT_CODE === 'TRUE') {
config.plugins = [
istanbul({
include: ['src/**/*.js', 'src/**/*.vue'],
}),
...config.plugins,
]
}
export default configSimilarly, in the Cypress plugin config: /**
* @type {Cypress.PluginConfig}
*/
module.exports = async (on, config) => {
if (process.env.VITE_INSTRUMENT_CODE === 'TRUE') {
require('@cypress/code-coverage/task')(on, config)
}
return config
} |
|
Yeah @iFaxity my solution was definitely a bit hacky -- I know very little about instrumenting or source maps, so I went with the most "direct" way to instrument the |
|
Yeah me neither, ill add the ENV variable too so it doesn't break your code. 👍 |
|
Version 2.1.0 should fix this, I ended up using the env variable VITE_COVERAGE instead. Then you can also use the new cypress option along with requireEnv to explicitly require the CYPRESS_COVERAGE variable to be set in order to instrument the code. I haven't tested it thoroughly though, only tested with simple Vite demos of React and Vue. Can you verify that it is working? |
|
In the PR above, I managed to have coverage with @cypress/vite-edv-server by making sure the instrumentation transform is done last, on simpler JS. I am not even sure that the babel options are necessary. Nor the special treatment of Vue SFC files. Tell me what you think. |
|
🎉 This issue has been resolved in version 2.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Thanks so much for this plugin, I would've been clueless without it!
Not sure if you're planning to continue maintaining this, but I had to tweak it a bit in order to instrument
.vuefiles. Wherepluginsis defined (which is later passed to Babel'stransformSyncfunction), I had to includeopts, like:Strangely, a couple of my
.vuefiles were instrumented without this, but not all of them... 🤔The text was updated successfully, but these errors were encountered: