1

Right now contract compilation and deployment results in bunch of artifacts and edits to swanky.config.json. I'm just curious what's recommended flow of dealing with those changes or developing smart contracts.

For example deploying compiled smart contract to local swanky node for development purposes results is many changes (artifacts, config edits) which will be pushed to VCS. Is this the desired way of handling things, what's the purpose of doing so? Maybe changes should be reverted before committing ?

1 Answer 1

1

Artifacts are a product of compilation, and swanky.config is a way for swanky-cli to track where those are, and which ones have been deployed and to what netwok/address, among other things. Ultimately, the decision what to commit to VCS is up to you, but discarding those changes and moving/deleting the artifacts might lead to unexpected behaviour. (such as swanky-cli deploying or calling the wrong contract or contract version)

2
  • Thanks. Touching swanky.config seems risky for me, but on the other hand development process produces lot of artifacts and deployment especially to local swanky node which lefts mess and these deployments cannot be visible across dev envs (local swanky nodes). I'm just trying to figure out best possible way for handling things out. Commented Feb 2, 2023 at 14:29
  • Let's put it this way: if you're not gonna use the previously compiled versions, or the address parameter to call the previously deployed contracts (tx and query commands default to latest), you can freely remove the artifacts with older timestamps, and older items from swanky.config's builds and deployments fields. If that turns out to a common pattern, we can consider changing how old artifacts are saved.
    – codespool
    Commented Feb 2, 2023 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.