fix(ssr): Transform named default exports without altering scope

[GrygrFlzr]

Fixes #4049.

Existing Behavior

Previously, given the following source files:

export default function() {}

export default class {}

export default function hello() {}
hello.test = 1234;

export default class A {}
export class B extends A {}

The SSR Transformer would indiscriminately replace the export default with __vite_ssr_exports__.default = as follows:

__vite_ssr_exports__.default = function() {}

__vite_ssr_exports__.default = class {}

__vite_ssr_exports__.default = function hello() {}
hello.test = 1234;

__vite_ssr_exports__.default = class A {}
class B extends A {}
Object.defineProperty(__vite_ssr_exports__, "B", { enumerable: true, configurable: true, get(){ return B }})

Which works for the anonymous cases, but alters the scope of named functions and classes, producing erroneous code that references undefined bindings.

Proposed Behavior

This PR instead reuses the Object.defineProperty technique already used for named exports:

__vite_ssr_exports__.default = function() {}

__vite_ssr_exports__.default = class {}

function hello() {}
hello.test = 1234;
Object.defineProperty(__vite_ssr_exports__, "default", { enumerable: true, value: hello })

class A {}
class B extends A {}
Object.defineProperty(__vite_ssr_exports__, "default", { enumerable: true, value: A })
Object.defineProperty(__vite_ssr_exports__, "B", { enumerable: true, configurable: true, get(){ return B }})

The options passed to Object.defineProperty are the same ones performed by TypeScript's esModuleInterop. The anonymous case is still handled in the same manner as the previous algorithm.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[GrygrFlzr]

The + 14 in the original code seemed like a horrible magic number, which is why I replaced it with a string length operation instead. If this is a cause of concern for performance, we can convert it back, I guess?

[GrygrFlzr]

I'm not sure why, but stripping out the newline from the source + target caused toMatchInlineSnapshot to insist that the lines were not equivalent. There might be a bug with its handling of single-line code?

[antfu]

Could apply .trim() to code before toMatchInlineSnapshot

[GrygrFlzr]

Post Notes

Prior to landing on Object.defineProperty, I did try to just append __vite_ssr_exports__.default = name at the end like so:

__vite_ssr_exports__.default = function() {}

__vite_ssr_exports__.default = class {}

function hello() {}
hello.test = 1234;
__vite_ssr_exports__.default = hello;

class A {}
class B extends A {}
__vite_ssr_exports__.default = hello;
Object.defineProperty(__vite_ssr_exports__, "B", { enumerable: true, configurable: true, get(){ return B }})

Unfortunately, this actually failed some tests with Vue SSR, probably because it doesn't quite replicate the proper export defaults.

As such, I wonder if it may be worth considering Object.defineProperty even for the anonymous cases like so:

Object.defineProperty(__vite_ssr_exports__, "default", { enumerable: true, value: __vite_ssr_exports__.default })

That said, no tests are failing without it, and I can't think of one that would fail without it right now. If someone has any concerns regarding this, please do comment on the PR.