sitecore-jss-rendering-host: webpack is still a runtime dependency for devServer, retired in #1426

[mvasin]

Describe the Bug

@sitecore-jss/sitecore-jss-rendering-host declares webpack in dependencies, but the only module that requires it is devServer, which was retired from the public API by #1426 (merged 2023-04-11) and is no longer reachable through the package entry point. The module and the dependency were left in the package.

Every consumer installing this package for ssrMiddleware or startRenderingHostServer, which is the documented production integration, therefore ships webpack and its dependency subtree into their production image for code that cannot be called.

I am filing this as a bug rather than an enhancement because the retirement decision was already made and landed; this is the part of it that did not happen.

To Reproduce

In 22.12.4, the current latest:

npm view @sitecore-jss/sitecore-jss-rendering-host@22.12.4 dependencies

{
  "del": "^8.0.0", "open": "^8.4.2", "ngrok": "^4.3.3",
  "express": "^5.1.0", "webpack": "5.101.0",
  "compression": "^1.8.1", "import-fresh": "^3.3.1"
}

types/index.d.ts exports four things, and devServer is not among them:

export { startRenderHostTunnel } from './tunnel';
export { ssrMiddleware } from './ssrMiddleware';
export { startRenderingHostServer } from './renderingHostServer';
export { getDefaultAppInvocationInfoResolver } from './defaultAppInvocationInfoResolver';

dist/cjs/index.js requires only tunnel, ssrMiddleware, renderingHostServer and defaultAppInvocationInfoResolver. Grepping the published tarball, the only files that require webpack are dist/cjs/devServer.js, dist/esm/devServer.js and types/devServer.d.ts. webpack-dev-server is the same: required from devServer and nowhere else, and it is not a declared dependency at all, so it arrives as an optional peer of webpack's own tooling.

No published version avoids this. Across all 1623 versions on the registry, none omits webpack from dependencies, and none declares it as a peer or optional dependency instead. The 23.0.0 canaries carry the same 5.101.0.

Expected Behavior

Installing the package for its production entry points should not install a bundler. After #1426 removed devServer from the public API, webpack should have stopped being a hard runtime dependency.

Possible Fix

Any of these would resolve it, in rough order of preference:

1. Drop devServer from the published package and remove webpack from dependencies. It has not been part of the public API since [sitecore-jss-rendering-host] Retire devServer #1426, so this affects only consumers reaching into dist/ directly.
2. Move webpack to peerDependencies with peerDependenciesMeta.optional: true, so only consumers who actually use devServer install it.
3. Move devServer behind a subpath export such as @sitecore-jss/sitecore-jss-rendering-host/devServer, with webpack as an optional peer.

Worth noting why this is not just tidiness. webpack declares webpack-cli as an optional peer, webpack-cli declares webpack-dev-server, and package managers resolve optional peers that are present in the graph, so a production install also picks up webpack-cli, webpack-dev-server, terser-webpack-plugin, esbuild and their subtrees. On our own production image, replacing this one dependency with a no-op stub removed 289 distinct packages, roughly 30% of the image's component count, with no behaviour change. It also removed a recurring class of vulnerability report, since advisories against webpack-dev-server and its subtree kept appearing in scans of an image that never loads any of it.

Consumers can work around it with a scoped override pointing webpack at a stub, and we have. That is a poor default: it requires knowing that devServer is dead, and it silently becomes wrong if the package ever loads webpack from a live path.

The same argument applies more weakly to ngrok, which is reached only from startRenderHostTunnel. That one is exported, so it is a real code path, but it is a development convenience that production consumers never call and that some organisations block outright. An optional peer would suit it too.

Provide environment information

• Sitecore Version: n/a, this is a published package defect rather than a runtime issue
• JSS Version: 22.12.3 and 22.12.4 (verified against all 1623 published versions)
• Browser Name and version: n/a
• Operating System and version (desktop or mobile): Linux container, Node 24, pnpm 11
• Link to your project (if available): not public