Sounds good. We can start to use Rollup alpha/beta as soon as you release them this time so we also help you better test the new Major. And even if there aren't big features by September, I think it is worth doing a Major release so you are free to use features from Node 18 after September when you see a good opportunity.

an alternative view: there's no shortage of major version numbers, I don't subscribe to the view that major versions have to be big splashes. major versions can simply be a single breaking bug fix, regardless of project size.

So that we have continuity of conversation I'll share this here as well: we'll likely start rolling out updates to drop Node v14 support for https://github.com/rollup/plugins in the second or third week of May. We're a bit short on help so that's likely to take a while to get through all of the plugins.

FWIW, not even the TypeScript compiler fully supports path resolutions, and I've found it easier to maintain projects (especially libraries) without it.

RE the vite-tsconfig-paths fork, that issue was fixed in April:

aleclarson/vite-tsconfig-paths#97

I'm using Vite with https://github.com/JeringTech/Javascript.NodeJS - They recently added support for ESM in the latest beta, but it still had some issues executing Vite output. I should try again, and see if it's still an issue.

So still relying on legacy.buildSsrCjsExternalHeuristics: true

Please let us know how it is working now. I think a bit of friction and some projects staying in Vite 4 may be a fair price to pay to remove this complexity though. Maybe you could create an issue there explaining your problem so they are aware of it.

There's an issue here - JeringTech/Javascript.NodeJS#160

Related comment down below.

CC @nitedani @iMrDJAi.

Let's continue discussing removal of SSR CJS format here:

• Removing `ssr.format: 'cjs'` #13816

How is this related to vite?

or auto-bundling css on a module level would be incredible. Useful for those making component libs

mark. a discssion here： #13617

Also this one: #10609

This PR has been there for 10 months already and solves a problem that no longer exists for cjs and esm since v3.something

Using rollupOptions might make it possible to:

rollupOptions: {
    preserveEntrySignatures: 'strict',
    input: '',
    output: {
        format: 'es'
    },
    external: option.external
},

here is a graceful way https://www.npmjs.com/package/vite-plugin-lib-inject-css, inject import statement at the top of each chunk file.

vite -d can't show the deep nested config props is a pain

very cool and useful idea. Is there an issue for this? @manucorporat

Related: #9367 which includes a proposal for how to handle linked dependencies.

Is this possible to add before v5?

Edited the post. Should we add a comment in the docs that Vite doesn't support Non Active LTS versions (odd-numbered) as soon as they become unsupported by node? As in not needing a Vite major to change this?

That sounds good to me 👍

yeah

Do you have something in mind? Falsy plugins are currently ignored so you can write the above snippet as:

export default defineConfig({
  plugins: [
    process.env.ENABLE_IMG_MIN === 'true' && ImageMin({ ... })
  ]
})

This only prevents to keep plugin typing.
Small issue, but may be fixed with a helper function like defineConfig

This is my biggest problem with Vite, I get errors in prod that aren't present in dev which means I need to always test prod because it's not an exact replication of dev which slows down the entire release process.
Cra is slow but it doesn't have this problem.

The last time this question was asked, the docs explaining why ESBuild isn't used for production builds was updated to say this:

Vite's current plugin API isn't compatible with using esbuild as a bundler. In spite of esbuild being faster, Vite's adoption of Rollup's flexible plugin API and infrastructure heavily contributed to its success in the ecosystem. For the time being, we believe that Rollup offers a better performance-vs-flexibility tradeoff.

That said, esbuild has progressed a lot in the past years, and we won't rule out the possibility of using esbuild for production builds in the future. We will keep taking advantage of new capabilities as they are released, as we have done with JS and CSS minification where esbuild allowed Vite to get a performance boost while avoiding disruption for its ecosystem.

Vite is written to tightly integrate and therefore mimic Rollup's plugin API and all of its idiosyncracies. That said, I could see Vite migrating to ESBuild (though probably not this year or next, if I had to guess). I say this because my experimentation with writing my own ESBuild-powered bundler (whose plugin API takes inspiration from Rollup) has proven successful (for my admittedly narrow use case as of this writing). For my experimental bundler, it took a ton of work to achieve this, so I'd expect it to be at least somewhat harder for Vite (as migrating is often more painful than building from the ground up). Luckily, a package that eases this transition has spawned out of my efforts. Its name is esbuild-extra and it provides a transformation pipeline that ESBuild is currently lacking, among other things.

Same opinion at #11299 (comment).

@iMrDJAi @nitedani Can you elaborate on why you still need CJS? AFAIK ESM should always be able to import CJS packages.

@brillout I don't need CJS, but I depend on libraries that are published in CJS format. CJS packages can be imported in ESM projects, but the ones with broken package.json exports no longer work. They used to work fine before Vite 4.

CJS packages can be imported in ESM projects, but the ones with broken package.json exports no longer work. They used to work fine before Vite 4.

Can you elaborate on that?

Making Vite always output ESM code is an import and foundational move. We shouldn't have any blind spots around this.

@iMrDJAi if they are broken shouldn't they be brought up to the current, correct standard instead of bending the tool?

Vite already compiles CJS libraries (like React) to ESM, so I don't think this is an issue.

You will probably get better responses to Vapor mode on the Vue Git site. Latest news I read is to tentatively expect it to arrive by the end of the year.

current vite competitor - Rspack (Webpack 1.1 is in progress and will be released to webpack and Rspack). If this feature is implemented in vite it ll be awesome

I would like to resonate with that. And top of that, if MF could finally be possible in dev mode.

That's a good idea

Yes you can check it at https://main.vitejs.dev/guide/migration.html

You need to use moduleResolution: 'bundler' (or node16/nodenext) to fix it. Rollup only export those types from the "exports" field which those resolution settings respect.

Worked like a charm! Thanks! 🙏

This is fixed in #15025 and will be released in the next patch (5.0.1)

Pressing "o" does work for me, but now I need to press Enter before the commands work. Same for "r". In the past you could simply press the key in terminal and it would perform the action.