Feature Request: File-based Solidity Compiler Version Mapping

[polus-arcticus]

Describe the feature

Feature Request: File-based Solidity Compiler Version Mapping

Problem

Currently, Hardhat's compilers configuration only allows specifying multiple Solidity versions, but relies entirely on pragma directives to determine which files use which compiler. This becomes problematic when:

1. Working with imported dependencies that require specific Solidity versions
2. Maintaining legacy contracts that must stay on older versions
3. Integrating new contracts that require newer versions
4. Wanting to avoid modifying existing contracts' pragma directives

Use Case Example

A project has:

• Production contracts that must stay on Solidity 0.8.7
• New forwarder contracts that use OpenZeppelin v5 (requires 0.8.20)
• Need to maintain audit validity by minimizing changes

Current workarounds (separate projects, downgrading dependencies) are not ideal.

Proposed Solution

Add a files pattern to compiler configurations:

solidity: {
  compilers: [
    {
      version: "0.8.7",
      files: ["contracts/**/*.sol", "!contracts/forwarder/**/*.sol"]
    },
    {
      version: "0.8.20",
      files: ["contracts/forwarder/**/*.sol", "@openzeppelin/contracts-v5/**/*.sol"]
    }
  ]
}

Benefits

1. Explicit control over which files use which compiler
2. No need to modify existing contracts
3. Better handling of dependency version requirements
4. Maintains audit validity by minimizing changes
5. More flexible than current pragma-only approach

Implementation Considerations

• File patterns should support glob syntax
• Should respect existing pragma directives as fallback
• Clear error messages when file patterns conflict
• Documentation updates to explain the new feature

Search terms

No response

[kanej]

We are taking a look at configuration patterns for solc in Hardhat 3. Let me ask the team whether this is currently possible in the Hardhat 3 alpha.

[kanej]

Just to add some more details here. In Hardhat 3 there is currently a concept of overrides for Solidity config - but they work on individual named files. To support this use case we need to support globs in overrides, which we will take a look at in the next few weeks.