feat(plugin-vite): add ability to ship esm bundle - #4184

Should we make the other .cjs?

Yeah, makes sense to me.

note: ESM preloads will only work in unsandboxed renderers according to the docs.

Since the Vite config doesn't have access to the parameters passed to the BrowserWindow constructor to allow us to pick the right format, we could account for that by tweaking the JSDoc in packages/plugin/vite/src/Config.ts to make this caveat clear, and maybe even adding some troubleshooting code like the following directly to the createWindow function in the Vite templates' main files to preemptively provide support for this issue:

// ESM preloads only work if your renderer is unsandboxed, which is disabled
// by default for security reasons. If your preload file fails to load and
// your renderer is sandboxed (i.e. the `webPreferences.sandbox` option in your
// `BrowserWindow` constructor is `true` or isn't set), please set
// `config.build.rollupOptions.output.format` to `commonjs` in your
// `vite.preload.config.ts` file.
mainWindow.webContents.on('preload-error', (event, preloadPath, error) => {
  if(preloadPath.endsWith('.mjs') &&

    // optional - these might be unnecessary or even wrong, but syntax errors
    // thrown when using `import` or top-level `await` in a non-ESM context
    // both contain the word "module" and they're bound to be the most common
    // ones in this scenario 🤷🏼
    // would be fine to omit these conditions, though, even if it means
    // showing this message for unrelated errors thrown in the preload.
    error.stack?.startsWith('SyntaxError') &&
    error.message.includes('module')
  ) {
    console.error(`Fail to load ${preloadPath}. Make sure you're using the \`commonjs\` output format in \`vite.preload.config.ts\` if your renderer is sandboxed.`)
  }
})

71e424c

🔴 The resolveForgeConfig ESM check accepts type: "module" with a main that does NOT end in .mjs, but packageAfterCopy's new extension check (line 338-345) unconditionally requires main to end in .mjs when outputFormat: 'es'. A user who fixes their package.json per the first error message will still crash later during packaging with a different, unrelated-looking error. Fix: make the early check require the same .mjs suffix (or drop the type: 'module' alternative) so both checks agree.

The merge in this branch replaced the static expectedExt check with a dynamic assertMainEntryExists fallback (now checking both .cjs and .mjs candidates), but the underlying disagreement is still there. vite.main.config.ts always emits [name].mjs when outputFormat: 'es' regardless of package.json's type field, so a user who follows resolveForgeConfig's advice and adds "type": "module" while leaving main as foo.js will pass the early check, then still hit a different error out of packageAfterCopy/assertMainEntryExists telling them to rename main to foo.mjs. The message is nicer now, but the two checks still don't actually agree — passing resolveForgeConfig via the type: 'module' branch does not guarantee success later. No test covers this end-to-end path (only resolveForgeConfig alone is tested for type: 'module' + .js main with outputFormat: 'es').