Skip to content

Conversation

@sapphi-red
Copy link
Contributor

Description

Updated Vite to fix the ecosystem-ci failure.
https://github.com/vitejs/vite-ecosystem-ci/actions/runs/15291891294/job/43012757806#step:8:5112

I've updated the snapshot, but I'm not sure if the change correct.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

  • It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
  • Ideally, include a test that fails without this PR but passes with it.
  • Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

  • Run the tests with pnpm test:ci.

Documentation

  • If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

  • Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

@netlify
Copy link

netlify bot commented May 29, 2025

Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit 70528ee
🔍 Latest deploy log https://app.netlify.com/projects/vitest-dev/deploys/683aab6b84f3cf00081e3b92
😎 Deploy Preview https://deploy-preview-8051--vitest-dev.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@sheremet-va
Copy link
Member

I don't think Vite update should affect how vue coverage is collected

@sapphi-red
Copy link
Contributor Author

sapphi-red commented May 29, 2025

Ah, no. The AST-aware coverage feature was just between them.
78a3d27

@sapphi-red
Copy link
Contributor Author

@sapphi-red
Copy link
Contributor Author

It seems vitejs/vite#19842 cc @hi-ogawa

hi-ogawa
hi-ogawa previously approved these changes May 30, 2025
Copy link
Contributor

@hi-ogawa hi-ogawa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for tracking down the diff. I think coverage change is reasonable and if anything, only Vitest side should adapt, so it should be good to merge.

Comment on lines 46 to 55
else if (isExperimentalV8Provider()) {
expect(coverageMap).toMatchInlineSnapshot(`
{
"branches": "6/8 (75%)",
"functions": "5/7 (71.42%)",
"lines": "14/17 (82.35%)",
"statements": "15/18 (83.33%)",
}
`)
}
Copy link
Contributor

@hi-ogawa hi-ogawa May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

v8-ast-aware shows +1 line/statement for default export statement compared to istanbul, but this seems more correct to me and I'm not sure it's a bad thing 🤔

Istanbul (Left)

  • Statements 3/5
  • Lines 3/5

v8-ast-awawe (Right)

  • Statements 4/6
  • Lines 4/6

Screenshot From 2025-05-30 09-12-32

@AriPerkkio I think export default didn't show up on v8-ast-aware coverage because it matches __vite_ssr_exports__.default = ... of ignoreNode, but is that intended other than for the sake of istanbul 100% matches?

// SSR transformed exports
if (
type === 'statement'
&& node.type === 'ExpressionStatement'
&& node.expression.type === 'AssignmentExpression'
&& node.expression.left.type === 'MemberExpression'
&& node.expression.left.object.type === 'Identifier'
&& node.expression.left.object.name === '__vite_ssr_exports__'
) {
return true
}

Btw, export default is now transformed to const __vite_ssr_export_default__ = ..., so I changed ignoreNode, this didn't have effect.

          if (
            node.type === 'VariableDeclaration'
            && node.declarations.length === 1
            && node.declarations[0].id.type === 'Identifier'
            && node.declarations[0].id.name === '__vite_ssr_export_default__'
          ) {
            return true
          }

The reason why I think new coverage is correct is that, this now treats following two statements as covered equally.

export const foo = defineComponent({ name: 'Foo' })  // covered

export default defineComponent({ name: 'bar' }) // covered

Istanbul and previous v8-ast-aware doesn't say export default to be covered and this seems like an issue of Istanbul.

export const foo = defineComponent({ name: 'Foo' })  // covered

export default defineComponent({ name: 'bar' }) // not covered

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should match 100% with Istanbul. Export-statements should not be included in coverage.

In this example:

export const foo = defineComponent({ name: 'Foo' })  // covered

export default defineComponent({ name: 'bar' }) // not covered

... the first one is a assignment and is included in coverage report. Second one is just export, and is not included. You should see this in practise with:

const foo = defineComponent({ name: 'Foo' })  // covered

export { foo } // Not covered

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's interesting, but I still don't comprehend the rational or underlying motivation. Why would users expect the behavior like this?

defineComponent({ name: 'bar' }) // covered

export default defineComponent({ name: 'bar' })  // not covered

Copy link
Contributor

@hi-ogawa hi-ogawa May 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there's a subtle nuance in export . I'm wondering what's the expected behavior of the following

export function f1() {} // not covered

export default function f2() {}  // not covered

export const f3 = function f3() {} // covered

export default (function f4() {}) // covered?

Based on vitejs/vite#19834, semantically we can see 4th example as:

const __internal__ = function f4() {}
export { __internal__ as default }

so making it covered doesn't look too wrong technically.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hi-ogawa I do agree with you that this is something that should likely end up in the coverage report. If we can get this fixed in istanbul-lib-instrument upstream, then we could do same for V8 in Vitest. For now we want 100% match between the two.

Copy link
Contributor

@hi-ogawa hi-ogawa May 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now we want 100% match between the two.

Sounds good 👍

Btw, I think there's one more edge case with export default. The transform can be seen in Vite test cases https://github.com/vitejs/vite/blob/54e0a18773be6f6c35d92db5be7f3e6159c23589/packages/vite/src/node/ssr/__tests__/ssrTransform.spec.ts#L518-L556 and the basic idea is:

export default function f() {}
// ⇓
Object.defineProperty(..., "default", ... f ...)
function f() {} 
export default class A {}  
// ⇓
Object.defineProperty(..., "default", ... A ...)
class A {}
export default otherCase
// ⇓
Object.defineProperty(..., "default", ... __vite_ssr_export_default__ ...)
const __vite_ssr_export_default__ = otherCase

The last case includes anonymous function and class. Probably this case needs to be kept "not covered" on our side even if istanbul changes the behavior of export default expr.

export default function () [}; 
// ⇓
Object.defineProperty(..., "default", ... __vite_ssr_export_default__ ...)
const __vite_ssr_export_default__ = function () {}

@AriPerkkio
Copy link
Member

I'm setting this as draft for a while - we need some adjustments for coverage. From Vite's side everything is OK.

@AriPerkkio AriPerkkio marked this pull request as draft May 30, 2025 18:16
@AriPerkkio AriPerkkio marked this pull request as ready for review May 31, 2025 07:41
Copy link
Member

@AriPerkkio AriPerkkio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

@AriPerkkio AriPerkkio merged commit e86282e into vitest-dev:main May 31, 2025
19 of 22 checks passed
@sapphi-red
Copy link
Contributor Author

Thanks for fixing!

@sapphi-red sapphi-red deleted the chore/deps-update-vite-to-6.3.5 branch June 1, 2025 08:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants