Run & review this pull request in StackBlitz Codeflow.

My take is that we should only expose this.parseAsync and parseAstAsync instead in Vite. I don't think we need the sync versions

Vitest uses this.parse for its mocking implementation and it's sync. Vitest also uses parseAstAsync to parse files for its type-checking feature. We don't use parseAst directly though.

@sheremet-va if Vitest uses this.parse, then I think we would have to move the initRollupParseAst back to buildStart or server init. Or Vitest will need to call it before using the function like this PR is doing. I don't know what is best here, it feels very wasteful to always load rollup/parseAst if it is only going to be used in some projects during dev.

@sheremet-va if Vitest uses this.parse, then I think we would have to move the initRollupParseAst back to buildStart or server init. Or Vitest will need to call it before using the function like this PR is doing. I don't know what is best here, it feels very wasteful to always load rollup/parseAst if it is only going to be used in some projects during dev.

this.parse API existed before parseAst was introduced (so before rollup 4). I don't think we can just stop supporting it, it might be used by projects other than Vitest.

I am fine with calling initRollupParseAst on Vitest side, it would just mean that Vitest 1.0 doesn't support Vite 5.1

this.parse API existed before parseAst was introduced (so before rollup 4).

And it existed because it's a rollup API so it doesn't need documentation.

this.parse API existed before parseAst was introduced (so before rollup 4).

And it existed because it's a rollup API so it doesn't need documentation.

I wrongly thought it was added in Vite 5, I got confused with it changing from acorn to use rollup/parseAst there.

I moved the init to be awaited in buildStart. So the only breaking change should be when calling the re-exported sync parseAst from vite before buildStart is called, and this function wasn't documented so we may be fine to merge this in 5.1 then.

/ecosystem-ci run vitest

📝 Ran ecosystem CI on ad32d57: Open

Does importing rollup/parseAst take time? I wonder if dynamically importing rollup and statically importing rollup/parseAst has a good balance.

Does importing rollup/parseAst take time? I wonder if dynamically importing rollup and statically importing rollup/parseAst has a good balance.

This is an option too. I'll try to get some numbers after we merge #15621 and rollup is no longer statically imported. If we do this, maybe it still makes sense to remove the static parseAst re-export so the ecosystem doesn't start to use it (given that it wasn't documented)

closing, it is now better to avoid the breaking change and directly move to rolldown