Provide type support to wrapper.ts

[stephen-slm]

Why

This change provides some basic type support for the internal and exported methods within wrapper.ts. The target result of this PR is to increase readability, maintainability and start the introduction of types. This additionally exports types out to the consumer of the solc module for consuming by the user. These are the following:

Depends on #614

Note

This is currently rebased on #614 so just validate the latest commit.

[coveralls]

Coverage remained the same at 84.537% when pulling 85dd58d on stephensli:type/wrapper into 05a1955 on ethereum:master.

[r0qs]

Hey, @stephensli thank you very much for this amazing work! :)
I took a look at your PR and made some comments. Some comments require discussion with the rest of the team to decide on the best directions. But I would appreciate your input on them as well.

[r0qs]

I know that this PR did not introduce this, but since we are doing some refactoring already, maybe we could move the types to a more proper directory. I don't particularly appreciate that the helpers.ts and types.ts share the same common directory.

We don't need to do it in this PR, but maybe it is not that much effort to do it now. And I would appreciate some suggestions on this.

I think we could have a types folder under the root, or maybe src/types, with the type definitions and move the source to a src directory.
Then in the types folder, we can add a index.ts with the types we want to export because we may not want to export everything to the consumer.
I believe this would require changing the tsconfig.json to something like:

 "rootDirs": ["src"],
 "typeRoots": ["./src/types", "node_modules/@types"]

The type declarations should follow the same directory layout of the source. For instance, bindings types would be under types/bindings.

Also, everything (source and types) is currently emitted together under the dist. And since we are adding support to types, I think it is a good opportunity to turn off "declaration" in the tsconfig.json and build the types separately, like so: npx tsc --emitDeclarationOnly --declaration --outDir dist/types

We can also add it as a script in the package.json.

[r0qs]

Hey @stephensli, we decided that this can be considered out of the scope of this PR. We can make this change later. So please ignore this comment here for now. I hope you didn't spent time on it :)

Let me know if you need any help to finish this PR so we can get it merged :D

[stephen-slm]

Sounds good, i'll try and find some time during the week to complete the remainder otherwise it will be completed on the weekend.

[r0qs]

Is this necessary?

[r0qs]

Maybe we should expand in the description of these parameters?

[stephen-slm]

Yeah happy to update, what would you like these to be described as for any consumer to understand?

[r0qs]

Sure, for instance:

/**
 * Compile a single file.
 *
 * @solidityMaxVersion 0.5.0
 *
 * @param input The JSON formatted compiler standard input
 * @param optimize A flag for enable/disable compiler optimization
 */
export type CompileJson = (input: string, optimize: boolean) => string;

[r0qs]

Maybe we can also add:

    "noEmitOnError": true,
    "noImplicitReturns": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true

[r0qs]

And if we decide to emit the type declarations separated from the source explicitly, we can set the declaration to false here.

[stephen-slm]

Hey, @stephensli thank you very much for this amazing work! :) I took a look at your PR and made some comments. Some comments require discussion with the rest of the team to decide on the best directions. But I would appreciate your input on them as well.

@r0qs Thank you for reviewing, anything to do with code changes are entirely out of scope of this PR as this is purely regarding the type information. It does not mean it's not valid but we should try keep it focused until this is complete.

I will go through and still reply to everything.