Skip to content

No way to specify additional PROVIDERS in ImportsResolver.groovy #40

Open
@antonydenyer

Description

@antonydenyer

I want to be able to specify different providers so I don't have to provide pathRemappings.

Activity

xaviarias

xaviarias commented on Sep 6, 2021

@xaviarias
Contributor

Hi @antonydenyer ! Ok which provider would you want? We can add it for the next release.

For now the only extension mechanism is specifying your own package.json file and add path remappings.

Or, would you have another suggestion on how to add providers dynamically?

Thanks

antonydenyer

antonydenyer commented on Sep 6, 2021

@antonydenyer
ContributorAuthor

👋

It's basically to get around having to do the following in my build gradle

solidity {
  resolvePackages = false
  pathRemappings = ['@consensys-software' : "$rootDir/permissioning-smartcontracts/node_modules/@consensys-software"]
}

Ideally, I'd like to be able to just add @consensys-software to the list of providers something like:

solidity {
  providers = ['@consensys-software']
}

perhaps?

xaviarias

xaviarias commented on Sep 6, 2021

@xaviarias
Contributor

The issue with that is @consensys-software is not the NPM package, but @consensys-software/permissioning-smart-contracts.

Maybe if we add a property named packages or npmPackages instead of providers, then that would be clear that the package name is required in order for this to work.

What do you think @antonydenyer ?

xaviarias

xaviarias commented on Sep 6, 2021

@xaviarias
Contributor

In any case, we can already add this package to the defaults.

antonydenyer

antonydenyer commented on Sep 6, 2021

@antonydenyer
ContributorAuthor

Ahh yes:

solidity {
  providers += '@consensys-software/permissioning-smart-contracts'
}

is what we want.

I think it's probably worth explaining what we are trying to achieve.

We want the following import to work as it does with truffle.

import "@consensys-software/permissioning-smart-contracts/contracts/NodeRules.sol";

In an ideal world having the defaults would be enough.
So maybe doing something to match the import with package.json and resolve it to node_modules?

self-assigned this
on Sep 7, 2021
xaviarias

xaviarias commented on Sep 7, 2021

@xaviarias
Contributor

We could just add it to the ImportsResolver and release a new plugin version. This would add it to the path remappings as well as the allowed paths.

The only objection I have is that the Consensys permissioning contracts do not implement any standard, so that would mean adding to the default packages a non-EIP library, opening the door to many other user packages.

I think we should stick to a clear demarcation criteria on what should be added as a plugin default provider, and for now EIP implementations are the only reason I think a package should be added.

jclagache

jclagache commented on Feb 25, 2023

@jclagache

Workaround to use the @uniswap/v3-core package instead of the out of date @uniswap/lib :
package.json :

{
    ...
    "dependencies": {
        "@uniswap/v3-core": "1.0.1"
    }
}

build.gradle :

solidity {
    evmVersion = "constantinople"
    resolvePackages = false
    pathRemappings = ['@uniswap' : "$projectDir/node_modules/@uniswap"]
}

You can then import Uniswap contracts, libraries and interfaces :

import '@uniswap/v3-core/contracts/interfaces/IUniswapV3Pool.sol';
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    No way to specify additional PROVIDERS in ImportsResolver.groovy · Issue #40 · LFDT-web3j/web3j-solidity-gradle-plugin