"packagizing" the useCompiler

[manuelwedler]

We use a function useCompiler in various places to compile contracts. This function provides a small wrapper around the solc compiler in order to download it and invoke the compilation.

The code was duplicated across multiple places, namely in the tests of lib-sourcify, in serverless/compiler-lambda and in the server code. In order to minimize the effort for maintenance and synchronization of these code parts, they should be moved into a public package. Basically the content of services/server/src/server/services/compiler/local/solidityCompiler.ts should be the content of the new package.

Tasks

Preview Give feedback

1. Create new package compiler-wrapper making the functionality of solidityCompiler.ts available
2. Use the package inside the tests of lib-sourcify
3. Use the package inside serverless/compiler-lambda
4. Use the package inside the server

[marcocastignoli]

My proposal is to build this package with the idea of shipping multiple compilers in mind. For example doing something like this: https://github.com/lodash/lodash/tree/4.5.0-npm-packages. (We can actually do the same thing just by having multiple compilers under packages/)

The final objective should be being able to do something like this in nodejs

import { CheckedContract } from "@ethereum-sourcify/lib-sourcify"
import {initCompiler} from "@ethereum-sourcify/compilers/solidity/nodejs"

const compiler = initCompiler(...)
const contract = new CheckedContract(compiler, metadata, sources);

And something like this in the browser

import { CheckedContract } from "@ethereum-sourcify/lib-sourcify"
import {initCompiler} from "@ethereum-sourcify/compilers/solidity/browser"

const compiler = initCompiler(...)

const contract = new CheckedContract(compiler, metadata, sources);

And something like this in the lambda function

import {useCompiler} from "@ethereum-sourcify/compilers/solidity/nodejs"

exports.handler = async (event) => {
    return {
      success: true,
      body: await useCompiler(
        event.version,
        event.solcJsonInput,
        event.forceEmscripten
      ),
    }
};

[marcocastignoli]

I'm adding here more context regarding this task after analyzing #1665 and #1784

New package: @ethereum-sourcify/compilers

• Keep in mind we have multiple languages and each can have multiple versions, and potentially multiple stages in the compilation
  • Languages
    • Solidity
      • solc
      • solcjson
      • solar
    • Vyper
      • vyper-c

(This is just the executable compilers, not interfaces, Interfaces should still be in lib-sourcify)