I would say that this is an outdated assumption. BuildInfos should include the compiler type, so we should run the same download logic here.

See this change where I added compilerType to SolidityBuildInfo: 6ed3056

We could create a partial SolidityCompilerConfig like this:

import type { SolidityBuildInfo } from "hardhat/types/solidity";
import type { SolidityCompilerConfig } from "hardhat/types/config";

function getPartialSolidityCompilerConfigFromBuildInfo(
  buildInfo: SolidityBuildInfo,
): SolidityCompilerConfig {
  return {
    // This cast may result in a "type" that no plugin can handle. So we should
    // probably have a way to know if a handler downlaoded a certain compiler,
    // and throw otherwise. This can't be done with parallel one, but can be
    // done with chained ones.
    type: buildInfo.compilerType as SolidityCompilerConfig["type"],
    version: buildInfo.solcVersion,
    settings: buildInfo.input.settings,
  };
}

There's no way to know if the buildinfo was built with wasm solc, but that's ok. We were already doing preferWasm: false below

Small tip: Moving the implementation of the handler into a separate file makes the test nicer.

The way we tend to think about it is this:

• If the handler requires the context, we may keep the implementation there, and use more integration-like tests.
• If the handler is more pure, we separate it and unit test it.

For example, this test file has hooks.setContext({} as HookContext); which I don't really like. It assumes that the HookContext is not used b any of the tests. I'd rather unit-test the handler.

This is a surprisingly nice pattern

I guess the changes in this file from here on in fact belong to #8008, but it's not important. Just mentioning it for my future reference and clarity.

Reviewed these changes. LGTM

I'm more of a fan of multi-level maps than this combined keys, as the type system enforces that you give them some thought. I'm not agains this either.

I like this. The buildProfile.preferWasm shouldn't affect any other compiler type. I actually forbid using it for build profiles with non-solc compilers in 558ec52

Just for future reference: in actual plugins we return new resolved config objects rather than modifying it. Otherwise understanding what's going on in the presence of multiple plugins gets really tricky.