fix(ssr): this in exported function should be undefined#18329
fix(ssr): this in exported function should be undefined#18329patak-dev merged 3 commits intovitejs:mainfrom
this in exported function should be undefined#18329Conversation
|
|
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
/ecosystem-ci run |
|
vite-environment-examples and vitest are failing with snapshot diff caused by stacktrace change ( |
|
📝 Ran ecosystem CI on
✅ analogjs, astro, histoire, ladle, laravel, marko, nuxt, previewjs, quasar, qwik, rakkas, redwoodjs, storybook, unocss, vite-plugin-pwa, vite-plugin-react, vite-plugin-react-swc, vite-plugin-svelte, vite-plugin-vue, vite-setup-catalogue, vitepress, vuepress |
|
This change makes sense, but it might be affecting Vitest coverage a bit. Other than stacktrace, I found one coverage test is failing when testing with a local build. It's only one test case with Vue (specifically this one |
AriPerkkio
left a comment
There was a problem hiding this comment.
Is it intentional that __vite_ssr_identity__ is left on source maps? It's not code that end user wrote, it's generated code added during transform. Leaving it in source maps doesn't sound correct to me. It will make coverage results wrong, but also makes debuggers stop in transformed code.
This is also an issue in other Vite's generated helpers so this concern might be out-of-scope of this PR.
We've been removing these from source maps on Vitest's side manually. I think this pattern has to be added there as well:
|
@AriPerkkio What do you mean by left on source map? Is it the mapping from |
There was a problem hiding this comment.
Is it the mapping from
__vite_ssr_identity__(to the space on the original source in this example with sourcemap visualizer?
That actually looks correct, the line 3 is not included there. Somehow it ends up in source maps in Vitest though: https://evanw.github.io/source-map-visualization/#MjIyO.... But that might be an issue just on Vitest side.
That said, I don't know how to do that in a performant way, I think we need to improve magic-string to achieve that.
The prepend and append methods do not modify the source maps, as there is no previous mapping when adding new content. So the implementation on this PR is correct in that way.
Description
thisin exported function should beundefinedbut it was not.reproduction in Node: https://stackblitz.com/edit/node-7bhlmx?file=index.js (make sure you run it locally, it works differently in stackblitz stackblitz/webcontainer-core#1532)
I used an identity function to avoid the
thisbinding.(0, foo.bar)can be used as well, but I thought it will be difficult for the same reason with #3682.