[heft] Webpack dev server URL should be displayed more prominently

[octogonz]

Summary

I created a similar GitHub issue for the webpack-dev-server project: webpack/webpack-dev-server#4907

But Heft has its own reimplementation of this logic, so @rushstack/heft-webpack5-plugin requires a separate fix, tracked by this issue.

Repro steps

1. Clone the Rush Stack monorepo
2. cd apps/lockfile-explorer-web
3. rush install && rush build -T . && rushx start

You will see output like this:

Heft helpfully prints the URL of the localhost dev server, however there are a couple usability problems with the design:

1. The URL is difficult to discern in those logs. The webpack-dev-server prints it using ANSI color, which is much better. Maybe we could even include an emoji such as ➡️ Started dev server at: https://127.0.0.1:8096
2. The URL is only printed once. After several rebuilds, it will get scrolled off the screen. The workaround is to kill and restart the dev server, but for large projects this can mean waiting several minutes for initialization.

Details

Heft's implementation is here:

rushstack/heft-plugins/heft-webpack5-plugin/src/Webpack5Plugin.ts

Lines 273 to 280 in 647e037

	onListening: (server: TWebpackDevServer) => {
	const addressInfo: AddressInfo | string | undefined = server.server?.address() as AddressInfo;
	if (addressInfo) {
	const address: string =
	typeof addressInfo === 'string' ? addressInfo : `${addressInfo.address}:${addressInfo.port}`;
	taskSession.logger.terminal.writeLine(`Started Webpack Dev Server at https://${address}`);
	}
	}

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question	Answer
@rushstack/heft version?	0.56.0
Operating system?	Windows
Node.js version (node -v)?	v16.15.1

[iclanton]

We could use the printMessageInBox function from @rushstack/terminal.

[dmichon-msft]

If running via https, it is helpful to emit as the host all accepted common names of the certificate, rather than just the IP address (which might not itself be one of said common names). I have logic for this in the rush-serve-plugin that we might consider borrowing here.

More broadly, I wonder if we might want to add some metadata category to task logs for information that should be surfaced at the end of a build, e.g. right before the "Waiting for changes" message.