Removing legacy.proxySsrExternalModules

[bluwy]

legacy.proxySsrExternalModules

• Added in vite@5.0.0-beta.11
• Rationale in feat!: remove ssr proxy for externalized modules #14521
• To be removed in Vite 6

If you have concerns, questions, or bug reports as to why you still need this option, please leave a comment here!

[sadiqsalau]

I'm importing some packages such as react-slick or react-fast-marquee, during build it works fine but throws error during SSR due to Vite exporting the module twice without this option..

vite.ssrLoadModule("...")

[Module: null prototype] {
  __esModule: true,
  default: { default: [Function: Slider] }
}

How to fix this without enabling this option?

[sadiqsalau]

Came up with a fix!

import __Slider from "react-slick";

const Slider = __Slider.default || __Slider;

[bluwy]

@sadiqsalau I tested react-slick in Node.js, and it seems like Vite is correctly aligning with it. E.g. this code in Node.js:

import mod from 'react-slick'
console.log(mod) // -> { default: [Function: Slider] }

And

console.log(await import('react-slick'))
// -> [Module: null prototype] {
//   __esModule: true,
//   default: { default: [Function: Slider] }
// }

If it works during build, could it be that you're bundling it during builds? E.g. if you have ssr.noExternal: true (bundle all deps), or ssr.noExternal: ['react-slick'], that means the library will be bundled.

[sadiqsalau]

Yes I'm bundling everything during SSR builds.. But while testing SSR during development, I get double export

[bluwy]

Yeah, in that case I think this is expected. The dependency is handled by Node.js in dev, and by Vite in build, so an inconsistency is expected here without Vite guessing the environment between dev and build.

Using const Slider = __Slider.default || __Slider; is the more appropriate solution for me for now then, compared to enabling the legacy option. Or you can also add the dependencies to ssr.noExternal so it's properly detected in dev (however the dep needs to be in ESM).

[sai-cb]

In case this feedback is helpful;

That I could experience, the ecosystem's state for node.js likely does not fit this removal well.

• Packages routinely only support CJS.
• Published types of packages tend to (inaccurately) assume interop.

So a few key points come to mind:

ESM without interop may be unrealistic

For any server project of a decent size, the task of writing strict ESM (without interop) may be too error-prone and require too much maintenance to be viable because of historical node.js and typescript decisions.

Providing interop support would match browser builds:

That's solution 1 (Make prod match dev behaviour). Although I understand supporting externalized dependencies may carry different challenges, the final dev experience would be more consistent for Vite users across browser and ssr builds.

CJS builds need legacy.proxySsrExternalModules

Projects that still compile to CJS (as I suspect may be common for node.js projects) were not affected by this dev vs prod discrepancy and using legacy.proxySsrExternalModules seems still appropriate for these cases.

By CJS builds, I mean this:

build: {
  rollupOptions: {
    output: {
      format: 'cjs',
    },
  },
},

[bluwy]

Do you have an example where CJS isn't affected by the inconsistency? There should still be an inconsistency regardless of the output type, for example:

// input
import a from "dep"
console.log(a)
// output
const a = require("dep")
console.log(a)

If the input in dev has legacy.proxySsrExternalModules on, you'd actually access a.default if a.__esModule exists. But in prod where a is left as is, you're accessing { default: .., __esModule: true } instead.

[sai-cb]

I can provide a more concrete example, yes! Thank you for following up!

Let's say with lodash, it is published as CJS. As seems to be often the case, interop seems to be taken for granted by the ecosystem. Using a named import in ESM (e.g. import { once } from 'lodash';) does not produce any typescript error.

With the following config:

build: {
  rollupOptions: {
    output: {
      format: 'cjs',
    }
  }
},

Compiling the following code:

import { once } from 'lodash';

once(() => {});

Results in the following, which is safe:

"use strict";
const lodash = require("lodash");
lodash.once(() => {
});
//# sourceMappingURL=backend.js.map

Yet this code, loaded through ssrLoadModule gets this error (unless proxySsrExternalModules is true):

|- SyntaxError: [vite] Named export 'once' not found. The requested module 'lodash' is a CommonJS module, which may not support all module.exports as named exports.
CommonJS modules can always be imported via the default export, for example using:
import pkg from 'lodash';
const {once} = pkg;

So at least in this this case, it seems like the removal of proxySsrExternalModules is what actually introduces a mismatch between the dev and production behavior.

--

That being said, I understand that the intent is to push projects to use ESM, which is great.

The overall issue is, without proper interop support (of the like spa apps are currently getting), given the state of the ecosystem, it may be unrealistic for many projects to take that step. There is a missing safeguarding piece that Vite is not providing.

Server ESM currently seems to result in significant (often likely unsustainable) manual work with little to no automated discoverability as to when using named imports is safe or not. And resulting production builds are more at risk of runtime crashes. Due to this, the current approach may have the opposite intended effect; push Vite users back to safety (CJS).

[remorses]

I don't understand why Vite can't do this transformation const Slider = __Slider.default || __Slider; automatically, there should be no difference between prod and dev, you just add that transformation in prod too

[remorses]

Can't you run the vite:import-analysys plugin during ssr? transforming the imports that are commonjs modules adding the following code:

// before
import Slider from 'react-slider'
// after
import __Slider from 'react-slider'
const Slider = __Slider.__esModule && __Slider.default ? __Slider.default :  __Slider;

This is what the user has to do anyway, so why not do it automatically and avoid TypeScript errors?

From what i understand you don't need to control modules loading to do this, you can do it as a transformation for files processed by Vite, tranforming the output of vite build --ssr

[bluwy]

1. It's not reliable to tell if the dependency if CJS. node --condition could change it.
2. If we unconditionally add the wrapper, not just default imports but also named imports, it breaks all ESM live bindings.
3. What if the dependency is re-exported?
4. How do we handle dynamic imports?
5. The issue still exists within dependencies not handled by Vite.

[remorses]

Thank you for responding, I wonder how other bundlers solve this, for example Next.js, which still externalizes server dependencies.

At first glance it seems they add a package.json with type: "commonjs" in the dist directory and bundle everything to commonjs, using import() for esm dependencies.

[remorses]

In my opinion this problem should have been solved in Node.js long ago, handling __esModule. Maybe it could still be done adding a flag. But telling people to add the .default workaround and break typescript types is the worst solution

[bluwy]

Yeah if Node.js also respected __esModule, that would be the most compatible. Though with what we have now, I wouldn't ask people to add .default as a workaround though, and instead request library maintainers to make it node-compatible if it's meant to be used in node. Vite has historically pushed libraries to properly package their code, and I think we can keep that going.