Rollup 3.0 stable was released! 🥳

Pushed a commit to handle pure CSS chunks mapping between renderChunk and generateBundle, as the !~{XXX}~ placeholder in the chunk.fileName interferes with comparisons.

I also noticed a strange error when running pnpm dev in packages/vite and pnpm test in the root. Getting this from Vitest:

Error: Parse failure: Unexpected token (52:24)
Contents of line 52:            this.#head =          ;

Can't find the source, but it's in Vitest's chunk-integrations-coverage.cca09977.js file that's having issues. pnpm build then pnpm test works fine.

I also haven't fully reviewed the assertions addition, but I assume we want that to be optional by default?

Pushed a commit to handle pure CSS chunks mapping between renderChunk and generateBundle, as the !~{XXX}~ placeholder in the chunk.fileName interferes with comparisons.

Awesome! And this made it all green!

I also noticed a strange error when running pnpm dev in packages/vite and pnpm test in the root. Getting this from Vitest:

Error: Parse failure: Unexpected token (52:24)
Contents of line 52:            this.#head =          ;

Can't find the source, but it's in Vitest's chunk-integrations-coverage.cca09977.js file that's having issues. pnpm build then pnpm test works fine.

Where are we using private properties? 🤔

I also haven't fully reviewed the assertions addition, but I assume we want that to be optional by default?

What we did so far is pass empty objects (meaning no type assertions) to resolveId et al options because they now require it. I think we should emulate what rollup does and forward the assertion so plugins can decide what to do with it. What do you mean by making it optional by default?

Can't find the source, but it's in Vitest's chunk-integrations-coverage.cca09977.js file that's having issues. pnpm build then pnpm test works fine.

Maybe #10740 will fix this. It sounds similar.

Ah yes that should fix it. The raw code had this.#head = undefined; so that explains the error message.

What we did so far is pass empty objects (meaning no type assertions) to resolveId et al options because they now require it. I think we should emulate what rollup does and forward the assertion so plugins can decide what to do with it. What do you mean by making it optional by default?

Yeah I noticed that Rollup now supports assertions too, but I think the API should have the property optional, e.g. you don't need to pluginContainer.resolvedId(id, importer, { assertions: {} }) everywhere. assertions should fallback to {} instead if undefined by itself, so you'd only have to do pluginContainer.resolvedId(id, importer)

pnpm dev and pnpm test works for me now after merging main. I also made the assertions optional following my comment above, but happy to revert that if I mistaken the change.

I also made the assertions optional following my comment above, but happy to revert that if I mistaken the change.

Looks good! It seems I checked one of the internal rollup definitions where Lukas is forcing the code to pass empty assertions to be explicit. Your change should be good on our side.
Let's merge this so tomorrow we can start the alpha.

/ecosystem-ci run

📝 Ran ecosystem CI: Open

Thanks for this PR and early release of pre 4.0!

Any feedback if you test v4-alpha.0 is appreciated @jacekkarczmarczyk! Our idea is to work with the ecosystem to fix the issues vite-ecosystem-ci uncovered above and ask for wider testing at a later stage (probably for beta.1 as usual). We are going to try to keep Vite 4 smaller than v3, so if things goes well, we should be able to release it mid-december

Sure, I'm going to try it out today on the code from my issue here as well as on my actual project (which is yet to be converted to vite, because of that problem)