/**
 * Integration test: real `npm` and `pnpm` subprocesses read the
 * Superblocks-owned userconfig when our env overlay is set. Pins the
 * contract that `buildInstallEnv` and the dev-server startup install
 * rely on.
 *
 * Why this exists:
 *   - Unit tests assert the spawned `env` includes the userconfig keys,
 *     but they cannot tell us whether npm/pnpm actually *honor* them.
 *     Earlier iterations of this PR tripped on two real CLI gaps that
 *     the unit tests missed:
 *       1. pnpm up to 11 rejects `--userconfig=` as a CLI flag
 *          (pnpm/pnpm#6036); 12 accepts it. The flag is therefore not a
 *          portable route and the overlay uses env vars instead.
 *       2. pnpm 10 ignores `PNPM_CONFIG_USERCONFIG`; an early pnpm 11
 *          ignored `NPM_CONFIG_USERCONFIG`. Setting both covers every
 *          major, so that is what `buildInstallEnv` does.
 *     The pnpm we spawn belongs to the customer's project, not to us,
 *     so it can be any major. Assertions that depend on the major
 *     branch on it rather than assuming ours.
 *   - This file spawns the real binaries and asserts the registry
 *     comes back from our fixture userconfig.
 *
 * Env scrubbing: pnpm/npm inject many `(npm|pnpm)_config_*` env vars
 * into spawned child processes. Those take precedence over userconfig
 * (env > userconfig in the npm config priority chain), which means the
 * fixture would be silently overridden if we forwarded the test
 * runner's env as-is. We strip those vars on the spawn so the assertion
 * exercises the userconfig pathway in isolation.
 */
export {};
//# sourceMappingURL=userconfig-env.integration.test.d.mts.map