You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since core contracts are guaranteed to be available by the FVM, it would be useful to have these automatically be recognized by flowkit/added to the state.
For packages depending on flowkit & using the state to resolve imports (i.e. Flow CLI, Cadence Language Server), they would be able to resolve these contracts via the new import syntax (i.e. import "MetadataViews")
(Optional): Suggest A Solution
Add the contracts with their aliases to Contracts() in the flowkit state by default.
Pros
don't have to declare existence/address of contract guaranteed to be deployed
smaller flow.json files
quicker development
other packages depending on flowkit do not need to make this consideration in their code constantly (not super easy to do currently & bug prone)
Cons (most of the cons are related to potentially obfuscating the underlying source code)
Potential namespace clashes if the user wishes to use own contracts which share the name of core contracts (user contract could take precedence here?)
Difficult to resolve source code of core contracts with currentconfig.Contract type. Since there would not be source file path in the config.Contract definition. Packages using flowkit may need a way to resolve the source code & this may mean flowkit needs to export this code from flow-go and expose it somehow
Harder for developers to inspect source code for these contracts when developing & trying to understand the code they are referencing. Likely need good support in the Cadence Language Server for "go to definition" so that developers can quickly discover the underlying code.
This may also be solved/greatly simplified by contract manager and this issue could become obsolete (see #929)
The text was updated successfully, but these errors were encountered:
What are the core contracts in this definition. I would treat contracts that every developer are likely to interface against differntly. Th LS snd tools needs to be able to know about these. Like NFT/FT and the view stuff.
Also as long as there is a way to see the effective state and look at it that is also good.
Issue To Be Solved
Since core contracts are guaranteed to be available by the FVM, it would be useful to have these automatically be recognized by flowkit/added to the state.
For packages depending on flowkit & using the state to resolve imports (i.e. Flow CLI, Cadence Language Server), they would be able to resolve these contracts via the new import syntax (i.e.
import "MetadataViews"
)(Optional): Suggest A Solution
Add the contracts with their aliases to
Contracts()
in the flowkit state by default.Pros
Cons (most of the cons are related to potentially obfuscating the underlying source code)
config.Contract
type. Since there would not besource
file path in theconfig.Contract
definition. Packages using flowkit may need a way to resolve the source code & this may mean flowkit needs to export this code fromflow-go
and expose it somehowThis may also be solved/greatly simplified by contract manager and this issue could become obsolete (see #929)
The text was updated successfully, but these errors were encountered: