fix(plugin-legacy): avoid executing blank dynamic import

[nulladdict]

Description

Fix for CSP issue described in #4568

Additional context

---

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.

[tjk]

Can you remove the additional CSP hash and the references to it please?

[nulladdict]

Additional hash is for the dynamicFallbackInlineCode script, which checks for dynamic import support, prints the warning and loads the legacy bundle if necessary

[tjk]

Oh woops... for some reason I thought that empty string was one of the hashes. My mistake...

[patak-dev]

Thanks @nulladdict, great that this fixes the issue and we don't have to do something hackier. Any reason the PR is a draft?

[nulladdict]

Yes, I wanted to check everything once more, and I found a problem. The new banner code is completely gone from the modern bundle.

It's probably optimized away by the rollup as "dead code", since the expression doesn't do anything and has no observable side effects. I tried change around the way code looks, but couldn’t make the code stay. One thing that worked is naming the function and exporting it, but that still doesn’t feel right.

I know rollup has /*@__PURE__*/ annotation, but I don't know if something like @preserve annotation exists.

[patak-dev]

Yes, I wanted to check everything once more, and I found a problem. The new banner code is completely gone from the modern bundle.

Oh... fun 😄

It's probably optimized away by the rollup as "dead code", since the expression doesn't do anything and has no observable side effects. I tried change around the way code looks, but couldn’t make the code stay. One thing that worked is naming the function and exporting it, but that still doesn’t feel right.

We could console.log the function + some text, but I think that exporting it is even less intrusive. I don't see a problem doing that with a name like __vite_legacy_guard. I think we should try that.

[nulladdict]

I searched around a bit for other ways of preserving unused code, but haven't found any good alternatives. I'm not sure how safe it is to go the export route, but it looks like it might be the least intrusive way

[tjk]

Hm, this actually breaks the SSR build --

$ vite build --ssr src/entry-server.ts --outDir dist/ssr

~/dist/ssr/entry-server.js:36
export function __vite_legacy_guard() {
^^^^^^

SyntaxError: Unexpected token 'export'
    at wrapSafe (internal/modules/cjs/loader.js:984:16)
    at Module._compile (internal/modules/cjs/loader.js:1032:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10)
    at Module.load (internal/modules/cjs/loader.js:933:32)
    at Function.Module._load (internal/modules/cjs/loader.js:774:14)
    at Module.require (internal/modules/cjs/loader.js:957:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Module._compile (internal/modules/cjs/loader.js:1068:30)

[patak-dev]

But this was added only to the modern esmodule. Why is this present in entry-server.js? @tjk could you create a new issue for this? PR ideas are welcome, we can revert if not until we better understand the issue.

[tjk]

@patak-js #4818