FLIP: Contract Import Improvements

[devbugging]

This is a FLIP PR proposing a new cadence contract import syntax.

---

For contributor use:

• Targeted PR against master branch
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Updated relevant documentation
• Re-reviewed Files changed in the Github PR explorer
• Added appropriate labels

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/onflow/flow-docs/A1dFpzd2KM7qKpLq1p1PY1t6uYuP
✅ Preview: https://flow-docs-git-sideninja-contract-imports-onflow.vercel.app

[devbugging]

Removed PR by mistake so I'm pasting this from the previous PR #881

@bluesign

Few related questions/ideas mostly related to cadence

• versioning of contracts (import specific version of the contract) I think this is a must have for compose-ability. But also little risky/tricky
• dynamic import: ( import from variable to a variable )
• name service: this would be nice to have but also competing with existing community projects

Response:
versioning of contracts (import specific version of the contract) I think this is a must have for compose-ability. But also little risky/tricky

Yeah, I think there are a bunch of problems still needing to be solved but the nice thing about it is that we can do that as we learn more about it, it's not restricting any syntax at this point. Versioning is something that at this point I wouldn't like to solve as you mentioned is still a bit tricky and it might require some other solutions to come along. I don't want to do too much with this proposal so it's actually doable soon.

dynamic import: ( import from variable to a variable )
Good feature, but again maybe we can add that later if needed.

name service: this would be nice to have but also competing with existing community projects
Yes again this should just first be established and then incorporated in the syntax. That is the reason I'm not restricting the syntax too much yet.

Thank you for your input :)

[turbolent]

Nice, this is going to make tooling much better!

[turbolent]

As discussed, maybe point out this is only an example how a tool like the CLI may use the syntax proposed this standard, and the behaviour of the tools is not part of this proposal

[bjartek]

Have you consider supporting aliasing? The name of a contract is not unique across the chain and in the future I am pretty sure there will be more contracts that are called common names. Right now it is not possible to import two Profile contracts from two different addresses.

So something like

import Profile from find/Profile as FindProfile
import Profile from qvvg/Profile as QvvgProfile

for instance.

Also have you considered the short for of just using
import NonFungibleToken

Flow.json will have the inforamtion about that if it is not namespace. So if the contract part of flow.json contains

"conctracts" : {
  "NonFungibleToken" : "cadence/contracts/NonFungibleToken"
}

So sort of say that if you do not specify a from then from is implied. This might crash with things like Crypto?

[devbugging]

I see @bjartek that's a valid flag for sure, the only thing I'm not quite sure about is that it feels to me like this could/should be supported by Cadence natively. What do you think also cc @turbolent

[bjartek]

I guess the core need here is the ability to migrate state to a new version of a contract.

[turbolent]

Support for aliasing in imports has been requested before in onflow/cadence#1171.

@bjartek Great point that this is currently not possible, but is unrelated to what this FLIP is proposing.

[joshuahannan]

So it seems like this FLIP is only really for the syntax of how the import placeholders should work? It isn't about how they are actually replaced by apps or the CLI, right?

It isn't clear to me what the standard format for the namespaces should be. Should a specification for how we should construct the namespaced placeholders be a part of this?

[devbugging]

So it seems like this FLIP is only really for the syntax of how the import placeholders should work? It isn't about how they are actually replaced by apps or the CLI, right?

It isn't clear to me what the standard format for the namespaces should be. Should a specification for how we should construct the namespaced placeholders be a part of this?

@joshuahannan
It also defines the requirement for contract files to include flow.json that maps the value of a placeholder to an actual value on different networks. I don't think it would be useful to define tool implementations in FLIP, firstly because it's too language-specific and secondly I've already started the work on extracting flow.json to have its own place (repo) and with it the libs folder where multiple language-specific implementations of flow.json parsing will live allowing the development of this tools. That's why I purposely left out any definition of how that implementation should work.

The part about further defining the syntax is something that I'm interested in but at the same time it's really hard to define one (even the example I mentioned has some problems) so if you have some better examples for such a syntax I would love to hear it.

My idea for this FLIP is to keep it simple intentionally so we could address the most important DX improvements soon:

• make sure all contracts follow the same mechanism when stating imports (currently that is not true even within onflow repo)
• make sure the contracts published that have imports have a way to communicate what that import is actually resolving to on different networks
• allow developers switch tools without having to replace import syntaxes and how those are being then resolved

[turbolent]

• make sure all contracts follow the same mechanism when stating imports (currently that is not true even within onflow repo)
• make sure the contracts published that have imports have a way to communicate what that import is actually resolving to on different networks
• allow developers switch tools without having to replace import syntaxes and how those are being then resolved

You really nicely laid out the goals of this proposal, and I think it succeeds in addressing these goals, so +1 from me.
I don't think that this proposal needs to recommend or require any particular namespacing scheme.

[joshuahannan]

Yeah, that makes sense. I'm fine with this then. 👍