feat(vrowzer): finish vrowzer.build() with .env files, tsconfig and CommonJS dependencies

[kazupon]

Closes #36. Stacked on #77 (stage 2, HTML app builds).

This PR is the last stage of #36. vrowzer.build() now reads the .env files and tsconfig of the project, builds CommonJS dependencies for production, supports CSS Modules, and reports what it does not support.

What it does

• .env files:
  • import.meta.env exposes the variables with the client prefix (VITE_ by default) of .env, .env.local, .env.[mode] and .env.[mode].local, as in Vite.
  • Only the files of the project are read, not the environment variables of the host. They are not copied to the outputs.
  • The previews read them too, when ready() starts them.
• tsconfig: builds apply the tsconfig.json of the project, or the file of the new tsconfig option (Vite 8.3), e.g. JSX settings, experimentalDecorators, verbatimModuleSyntax, and paths with resolve.tsconfigPaths.
• CommonJS dependencies: with build: true, the manifest of @vrowzer/vite-plugin also has the original files of the CommonJS packages that it bundles into ES modules for the previews, e.g. react. Builds bundle them for production, as Vite does. The previews keep the ES modules.
• CSS Modules work in the previews and in builds (now tested, with composes).
• Warnings:
  • They keep the code, plugin, module, location and code frame of rolldown's warnings.
  • The errors that Vite logs without failing the build are returned with them.
  • The warning about large chunks is back.
• What builds do not support is reported, with the module and the location:
  • import.meta.glob(), dynamic imports with variables in their relative paths, and new Worker(new URL(...)) are warnings.
  • ?worker imports fail with a clear error instead of "default" is not exported.

How it works

• .env files:
  • env.ts takes the form of Vite 8.3.1. With NOTE(kazupon): it parses with dotenv's parse(), because the browser has no parseEnv() of node:util, and leaves out Vite Task's getEnvs().
  • config.ts calls loadEnv() again. Its envFile warning and envPrefix check are back, and so is the %ENV% prefix of html.ts.
  • dotenv-expand goes to ^13.0.0 with upstream's patch, which lets a variable use the ones of the other .env files. Upstream's test fails without it.
  • The Web Worker of the previews now writes the project files before it resolves the config, so that the config reads them. The fork's resolveConfig() does not load config files, so the project's vite.config.* is not read.
• tsconfig: builds pass config.tsconfig to rolldown and to the native transform and resolve plugins, as upstream does.
  • Without it, rolldown and the native plugins already found the tsconfig.json of each module.
  • The warning that resolve.tsconfigPaths has no effect is now for the previews only.
• CommonJS dependencies:
  • The original files go to .vrowzer-cjs/ inside each package, with the original package.json, so that they stay CommonJS: the rewritten package.json is type: "module".
  • Its exports give the development condition the ES module, and the other conditions ./.vrowzer-cjs/....
  • The targets stay inside the package, because the native resolver of builds rejects a target outside it (Invalid "exports" target).
  • build is part of the cache key, and scripts/generate-manifest.ts --build sets it.
• Warnings: a plugin of the builder wraps build.rolldownOptions.onLog. It calls the config's onLog, then Vite's handler, and adds the details to the warning that Vite logged, so Vite's handling of the logs does not change.
• What builds do not support: another plugin checks the JavaScript of the project's modules after the other plugins. Strings, comments and dependencies are left out.

Differences from the plan

• The original CommonJS files are inside each package instead of a shared directory, for the type and the resolver above.
• tsconfig applies to builds only. The previews do not read tsconfig, because their transform still has the old, stubbed path. Porting upstream's dev transform would touch the transform of every TypeScript file of the previews, so it is left for another issue.

Not supported, or not checked

• A development build (NODE_ENV=development, e.g. in a .env file) cannot resolve the CommonJS packages of the manifest: the development condition still points outside the package (../.vrowzer-esm/), which the native resolver rejects.
• Changes to .env files after ready() reach the next build, but not the running previews (upstream restarts its server).
• Browsers:
  • The build is tested in Chromium.
  • In WebKit 26 (Playwright), crossOriginIsolated is false, so SharedArrayBuffer is missing and Vrowzer itself does not start. The likely cause is that WebKit does not support COEP credentialless. This is outside Add vrowzer.build() for browser-side production builds #36.
  • Firefox could not be launched in my environment (a macOS sandbox restriction), so it is not tested.
• import.meta.glob, variable dynamic imports and the Workers of the project stay out of Add vrowzer.build() for browser-side production builds #36's scope. They are reported, not built.

Measurements

macOS arm64, Chromium:

• Host output:
  • the builder grows by 14,519 bytes to 1,404,471 bytes
  • the transformer of the previews grows by 12,114 bytes to 1,460,695 bytes (dotenv, because the previews read .env files)
• The manifest of build: true for the react e2e project gets the original files of react (169,358 bytes) and react-dom (7,317,229 bytes). Minified with Oxc, as the automatic manifest does, that is about 3.1 MB. The spike's estimate (549 KiB) counted only the production entries for browsers. Trimming the files to what the production conditions reach is left for another issue.

Tests

All on macOS (arm64):

• vp run build, the type checks, oxlint, knip and the format check pass.

• Unit tests: 2183 passed, 3 skipped (39 more than stage 2).

  • ported from upstream:
    • loadEnv() with its fixtures, and resolveEnvPrefix()
    • the test of the top-level tsconfig
    • the test that the library entry of the top-level input does not mutate the user config, missed in stage 1
  • new:
    • .env files in resolveConfig(), and the order of setupWorker()
    • tsconfig in builds in Node, including the tsconfig option and extends
    • the manifest for builds, and a build in Node that resolves its layout and bundles only the production branch
    • the details of the warnings in a build in Node
    • the reports of what builds do not support

• Integration tests:

  Project	Result
  fs	3 passed
  node-polyfill	769 passed, 6 skipped
  rolldown	4 passed
  service-worker-server	10 passed
  service-worker	27 passed
  unplugin-service-worker	63 passed, 1 skipped
  vrowzer	109 passed, 1 skipped (3 new)

  build.integration-test.ts gets a project with .env files, a tsconfig.json, CSS Modules and a CommonJS dependency in the layout of the manifest. In the browser, it checks:

  • the variables of the .env files in the preview (development) and the build (production), without the unprefixed ones and without the env files in the outputs
  • tsconfig in the build: the build Worker reads it from the snapshot
  • the production branch of the CommonJS dependency in the build, and its ES module in the preview
  • CSS Modules in the preview and in the build
  • the details of the warnings, and the warning about import.meta.glob()

• e2e, with the Vite caches cleared first:

  • dev mode: 46 passed, 6 skipped
  • host build mode: 39 passed, 13 skipped