WSL2 with Solidity plugin: Compile error: File import callback not supported

Hi, I just had the same issue using Vs Code insiders within Wsl2, and it took me a while but I determined the issue began after I compiled an individual sol file using the right click ‘compile this contract function’ that is enabled by the solidity extension is installed onto wsl2 (Juan Blanco authored). The extension attempted to download new binaries on the system during the compile. So I decided to take a break and let the download finish. And I didnt notice the import errors right away after I returned because the compile didnt finish and I initially thought it was network related. So I trouble shooted a few things and decided to remove the extension and the problem disappeared. This has NOT occurred on other contracts on my wsl2 system (all sol 6.12 version or 5.17, and all python based ethereum ).Those contracts are all pre-OZ upgrade era. And I have 30 plus contracts in several directories, one virutal python directory, but,the issue has not occurred in the 3 months I’ve developed using wsl2 and vscode but it certainly occurred while using webstorm in windows before i switched to wsl2 with docker back end and ubuntu distro,conclusion - the npm based oz, hardhat, and truffle installs into vs code wsl2 environment do not align well with vscode extensions, ie - the node resolver engines…Also it seems remixide has the same exact issue with the initializable.sol contract within windows chrome browser.,after getting past the initial error and getting everything ready to test, the only place the resolver would look is in the contracts folder within the directory, it didnt look within node modules at all, so now, i am going to move copies of the contracts out of node into my contracts folder which is defeating the purpose of plugins vs. sdks…if you want me to open an issue on github, let me know, and I will do so…thanks

$ npx truffle test

Compiling your contracts...
✔ Fetching solc version list from solc-bin. Attempt #1
Error: Could not find tknDafi/node_modules/@openzeppelin/contracts-upgradeable/AccessControlUpgradeable.sol from any sources; imported from /home/nocode326/da-fi/tknDafi/contracts/dafi_t.sol
    at Resolver.<anonymous> (/home/nocode326/da-fi/tknDafi/node_modules/truffle/build/webpack:/packages/resolver/dist/lib/resolver.js:62:1)
    at (<anonymous>)
    at fulfilled (/home/nocode326/da-fi/tknDafi/node_modules/truffle/build/webpack:/packages/resolver/dist/lib/resolver.js:5:42)
Truffle v5.1.57 (core: 5.1.57)
Node v10.22.0

and even after pasting the solidity upgradeable files into the same folder as my created contract file which again is filed as “project/contract”, the npm/npx/truffle trio could not find the files, I’ve never experienced anything like this with python. pythons path utilities go above and beyond and work quite well…and I think OZ would be well served offering a python variation of there upgrades…but perhaps brownie would be able to handle it as it, any thoughts? if not i will reach out to the creator of brownie and see what he says…

1 Like

Hi @rmourey26,

I am sorry you had this issue.

Can you share your contract and test, or a cutdown version (at least showing the imports and inheritance)? That way I can try to reproduce.

I have a simple fixed supply ERC20 upgradeable example using Truffle that you could try: Create upgradeable ERC20

****update—keep in mind I am trying to implement an updgradedable Preset ERC20 minterpauser. I was able to move past the Access Control upgradeable issue i mentioned previously by moving the contract itself from the node folder to my contracts folder. I was surprised I could do that but it allowed the compiler to move forward. Into the next error which was a very similar error but it referenced the “enumerable set upgradeable contract” and I was thinking that I needed to get some data into the contract using an array?..I’ve been thinking…Most of my contracts that Ive tested and deemed ready to deploy could be upgraded, using the word could because, at present its not needed 100%…these upgrades are relatively new, and although i love the long term thought process behind it, i am in a short term frame of mind until i deploy live and get some wind behind me if you know what I mean? And on the surface it seems like that if I decided to upgrade 20 plus contracts if not more, then I could open a pandoras box of work and thus delays…I just really want to get a simple token deployed, but make sure it can get upgraded when ready, have a fixed supply with a % allocation to owner…I have a Gnosis Multisig Safe already setup…Is there a way I can use the Gnosis to make this token deployment process easier and more importantly the maintenance and upgrades thereafter? I like what you guys are offering with the Defender - seems like it would be quite useful while running a defi app…?

1 Like

Well actually I did glance at your writeup previously and noticed you have gnosis worked in to your project…so I will check that out more thoroughly…,do you think its wiser to wait on going all in on these upgradeables? until I am up and running consistently and ahead of things…?

Hi @rmourey26,

To keep your system secure, you should always use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself.

You can use the PresetERC20MinterPauser as inspiration or you can extend from it. See:

It really depends on your use case, whether to deploy an upgradeable contract or a non-upgradeable contract. Though you can’t change a non-upgradeable contract to be upgradeable.

You can deploy as a non-upgradeable contract but you won’t be able to change it to an upgradeable contract.

I recommend looking through:

Yes. You can give your Gnosis Safe control of any admin functions, including control of any upgrades.


Defender is great if you have any admin functions in your contracts or you need to securely automate calling your contract.