Contracts, imports, and navigation

Start with a small contract#

Create Counter.sol in a Solidity project:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Counter {
    uint256 public value;
    event Changed(uint256 previous, uint256 current);

    function increment() external {
        uint256 previous = value;
        value += 1;
        emit Changed(previous, value);
    }
}

Use completion in the function body, inspect the contract in Structure, and navigate from Changed to its declaration. Find Usages on value should distinguish this state variable from an unrelated declaration in another contract.

Resolve dependencies#

Imports may resolve through project files, node_modules, Foundry layouts, or configured remappings. For a remapped import such as @openzeppelin/contracts/token/ERC20/ERC20.sol, inspect the actual package/remapping and installed file before changing editor settings.

Use Go to Declaration to verify which contract a base name resolves to. A successful parse does not prove the Solidity compiler will find a missing dependency at build time.

Inspect inheritance and ABI#

Open type/call hierarchy or structure views to follow inherited members and callers. Documentation and inlay hints can explain types, selectors, and gas-related information. ABI-oriented information depends on the contract and available compiler results; an editor hint is not a deployment.

Refactor with usages#

Use Rename on a declaration and review its resolved usages. Keep externally consumed ABI changes in mind when renaming public/external members: updating the source does not update off-chain clients or a deployed contract. Build and run the project’s tests after making an API change.

Continue with compiler and test workflows to check the contract with the project’s actual tools.