Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not support importing external libraries when using workspaces (like in yarn and lerna) #17

Closed
alesanro opened this issue Jun 13, 2019 · 5 comments · Fixed by #18
Closed

Comments

@alesanro
Copy link

In case of having several workspaces with packages and smart contracts imported libraries are searched only inside this package node_modules but probably should also have a shot on looking for upper-level node_modules like npm/yarn module resolution do.

@Aniket-Engg
Copy link
Owner

Hi @alesanro , Thanks for raising this. Can you please add steps to reproduce it? That will be really helpful

@alesanro
Copy link
Author

So basically I have the next project structure:

Screen Shot 2019-06-14 at 12 08 52 PM

where

  • TokenAirdrop -> contracts, TokenAirdrop -> utils are workspaces in terms of lerna
{
  "packages": [
    "contracts/*",
    "hunter-airdrop/*",
    "utils/*"
  ],
  "version": "independent",
  "npmClient": "yarn",
  "useWorkspaces": true
}
  • Workspaces contain their packages, like actions-tracking, actions-tracking-artifacts, etc.
  • actions-tracking is a package with smart contracts

Running yarn (link npm install) in workspaced environment installs equal dependencies from all packages in the root node_modules (some of them could have different version requirements so they will be installed locally in a package).
Screen Shot 2019-06-14 at 12 08 52 PM

  • in ActionsTracking contract there is the next code
pragma solidity ^0.4.24;

import "openzeppelin-solidity/contracts/access/roles/SignerRole.sol";

and sol-profiler tries only at ~/Documents/TokenAirdrop/contracts/actions-tracking/node_modules/openzeppelin-solidity/contracts/access/roles/SignerRole.sol.


It is expected that it could search like module resolution do: beginning from local node_modules and the going on the next level ../node_modules, ../../node_modules and so on.

@Aniket-Engg
Copy link
Owner

Aniket-Engg commented Jun 20, 2019

@alesanro I got your point. Actually contract with import is flattened using the package sol-straightener. To determine the path of node_modules folder, it uses default way suggested by npm using npm root.

Although it should work properly in this case too but I am not sure how we can incorporate the required changes.
Do you have something in your mind?

@alesanro
Copy link
Author

@Aniket-Engg Hi, I've made MR for sol-straighterer. I suppose that will resolve the issue and will allow to go through several node_modules folders, not only a single parent.

@Aniket-Engg
Copy link
Owner

That's great. I will review and merge it.

Aniket-Engg added a commit that referenced this issue Jun 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants