Use file-relative paths instead of project-relative

[adraffy]

Is your feature request related to a problem? Please describe.

These project relative paths:

optimism/packages/contracts-bedrock/src/libraries/Encoding.sol

Line 4 in a4c47fe

import { Types } from "src/libraries/Types.sol";

Describe the solution you'd like

Should be changed to file relative paths:

import { Types } from "./Types.sol";

Additional context

For example, these files cannot be used in Remix as the npm imports cannot disambiguate "src/"

This also causes issues with Foundry, where the same file is imported twice causing T != T errors.

[tynes]

Can you give a reproducible case that shows this error? Imports using this style are part of our style guide. They make refactoring much easier internally to the project. Perhaps we could raise this as an issue with remix?

[adraffy]

Yeah, I can submit a foundry repo and a remix project example.

IMO, that's a weird style guide recommendation, as the file is only refactored once. Every importer pays the price of translating project-relative includes.

For example, all OpenZeppelin and forge-std includes are file-relative.

[adraffy]

https://github.com/adraffy/optimism-project-relative-issue/blob/main/src/Contract.sol

1. foundryup
2. forge build

Compiler run failed:
Error (9553): Invalid type for argument in function call. Invalid implicit conversion from struct Types.OutputRootProof memory to struct Types.OutputRootProof memory requested.

[tynes]

Thank you for the repro case

[adraffy]

You can use the following one-liner to repro in Remix:

import "@eth-optimism/contracts-bedrock/src/libraries/Encoding.sol";

This will correctly import via NPM then fail with with: Error: not found src/libraries/rlp/RLPWriter.sol

[tynes]

I see, so relative paths are going to be more portable. I am curious if the following comment helps for the foundry case: foundry-rs/foundry#3440 (comment)