Openzeppelin vs truffle compile - different contract imports required (error)

Good day folks, I am back!
First things first, I am having a blast with the OpenZeppelin framework. 6 months ago I was using ZeppelinOS. I am very happy to see that the current state of OpenZeppelin is WAY more robust and developer friendly than ZeppelinOS was. No weird errors and bugs for me anymore. You guys really did a great job.

Now for my issue and question. I want to unit test my contracts with Truffle, as shown in the docs. This is working as expected. The thing that left me confused and wondering is a clash between OpenZeppelin and Truffle. In order to test with Truffle I have to run truffle compile, while OpenZeppelin uses it’s own openzeppelin compile.
My problem is requiring contracts located in the same project directory. OpenZeppelin wants me to code require("Contract.sol"); while Truffle wants to see require("./Contract.sol"). The Truffle approach is correct according to the Solidity documentation. For now, when I want to test my Contracts, I have to change the import line to the Truffle way and test the contracts, and when I want to deploy and/or upgrade, I change it back to the OpenZeppelin import. I think this is not the desired behaviour.

:computer: Environment
Truffle v5.0.41 (core: 5.0.41)
Solidity v0.5.8 (solc-js)
Node v10.16.3
Web3.js v1.2.1
OpenZeppelin v2.5.3
Windows 10 1903

:1234: Code to reproduce

Reference a contract the Solidity/Truffle way: require("./Contract.sol") and run openzeppelin compile results in the following output:

:heavy_multiplication_x: Compiling contracts with solc 0.5.12 (commit.7709ece9)
Compilation errors:
contracts\OtherContract.sol:5:1: ParserError: Source “Contract.sol” not found: File import callback not supported
import “./Contract.sol”;

As for the other way around: require("Contract.sol") and run truffle compile results in the following output:

Error: CompileError: /C/Users/mypath/contracts/OtherContract.sol:5:1: ParserError: Source “Contract.sol” not found: File import callback not supported
import “Contract.sol”;
Compilation failed. See above.
at Object.compile (C:\Users\mypath\node_modules\truffle\build\webpack:\packages\workflow-compile\legacy\index.js:72:1)
Truffle v5.0.41 (core: 5.0.41)
Node v10.16.3

My guess is this is a bug in OpenZeppelin, hope to hear back from you :slight_smile:

1 Like

Hi @Chrissie,

Glad you like the current state of OpenZeppelin SDK.

I don’t have a Windows development environment currently to reproduce.
Can you confirm that the following fails, along with the error message and I can create an issue.

I can compile with Truffle and OpenZeppelin CLI with a contract imported as import "./Contract.sol";
I am using Windows Subsystem for Linux. (and would recommend it for Windows users as I have far fewer issues than when I ran on Windows).


mkdir testimport
cd testimport
npm init -y
truffle init
openzeppelin init

Create the following contracts in contracts directory.


pragma solidity ^0.5.0;

contract Contract {


pragma solidity ^0.5.0;

import "./Contract.sol";

contract OtherContract is Contract {

truffle compile

$ truffle compile

Compiling your contracts...
> Compiling ./contracts/Contract.sol
> Compiling ./contracts/Migrations.sol
> Compiling ./contracts/OtherContract.sol
> Artifacts written to /mnt/c/Users/andre/Documents/projects/forum/imports/build/contracts
> Compiled successfully using:
   - solc: 0.5.8+commit.23d335f2.Emscripten.clang

openzeppelin compile

$ openzeppelin compile
✓ Compiled contracts with solc 0.5.12 (commit.7709ece9)

Thank you for your reply.
I can confirm the issue is a Windows issue, and on WSL I cannot reproduce the issue (it works as expected :slight_smile:)

I will be a happy Windows tester for you - if I encounter any other differences/bugs I will let you know. It would be great if OpenZeppelin works as expected for Windows too, I don’t know if you plan to actively support both platforms?

1 Like

Hi @Chrissie,

I have created an issue:

For now I suggest you use Windows Subsystem for Linux if you can. It would be good to resolve the issue so that you can compile easily on Windows.

Please raise any other Windows issues you find.