Making manual Solidity version management a thing of the past
When you’re a blockchain developer, managing Solidity installations sucks. It shouldn’t have to be this way, so we decided to do something about it. Any decent blockchain library worth its salt takes care of a lot of the heavy lifting for integrating with smart contracts. In the Web3j SDK when you create a new project, your smart contract code is automatically compiled for you at build time, with JVM bindings generated for deploying and transacting with that smart contract. To ensure the end-user experience is as seamless as possible here, we find ourselves constantly switching from one version of Solidity to another, and then another.
Any decent blockchain library worth its salt takes care of a lot of the heavy lifting for integrating with smart contracts. In the Web3j SDK when you create a new project, your smart contract code is automatically compiled for you at build time, with JVM bindings generated for deploying and transacting with that smart contract. To ensure the end-user experience is as seamless as possible here, we find ourselves constantly switching from one version of Solidity to another, and then another.
Don’t get left behind
Solidity releases move quite fast, and what might work under one version of Solidity might not work with another. Sometimes we want to use Solidity 0.5, other times we’re starting new projects running the newly released Solidity 0.6, and other times we’re supporting legacy projects which still use 0.4. Switching between these on our dev machines is often quite an annoying process that involves juggling multiple native installations, or using dockerized Solidity versions for each project.
In Web3j too, we need the capability to compile smart contracts targeting whichever version of Solidity that the end user chooses. Previously, we supported doing this by using a single Solidity version and allowing end users to use a different version if they needed to by reconfiguring our compiler plugin to use a local executable. This was functional, but difficult for new users, and led to considerable confusion on our issue tracker.
If only there was a library for that
Enter Sokt, our new library for managing multiple local Solidity installations, and programmatically compiling almost any Solidity file. Give any Solidity file to Sokt, and it will automatically determine the optimal Solidity version to compile it with. If that version is not installed, a solc binary will be downloaded for the current platform (either Linux, macOS or Windows) - no compilation from source is necessary, and there’s no dependency on Docker. Sokt can then invoke Solidity on your source files, creating whichever outputs are specified. The following example demonstrates how to use Sokt to compile a smart contract:
val fileName = “<path to your solidity file>”
println("sokt Processing $fileName")
val solidityFile = SolidityFile(fileName)
println("Resolving compiler version for $fileName")
val compilerInstance = solidityFile.getCompilerInstance()
println("Resolved ${compilerInstance.solcRelease.version} for $fileName")
val result = compilerInstance.execute(
SolcArguments.OUTPUT_DIR.param { "/tmp" },
SolcArguments.AST,
SolcArguments.BIN,
SolcArguments.OVERWRITE
)
println("Solc exited with code: ${result.exitCode}")
println("Solc standard output:\n${result.stdOut}")
println("Solc standard error:\n${result.stdErr}")
Sokt is written in Kotlin and works with any Java, Kotlin or Groovy project. It is also now fully integrated with Web3j (via the Gradle plugin), which results in better compatibility and developer experience when using the library. Sokt is also now a published artifact - so it can be used in your projects too, simply by adding a Gradle dependency:
compile group: 'org.web3j', name: 'web3j-sokt', version: '0.1.0'
By leveraging the mighty power of Sokt, you no longer have to manage Solidity installations yourselves. Hopefully, this will give you the opportunity to do other things with your precious time that doesn’t involve swearing at your computer when you realise it was picking up the wrong version of Solidity from your path.
