solc-js
solc-js copied to clipboard
ethereum
Adds Typescript definitions.
This isn't complete, but it is way better than nothing and gives a place for people to add additional typescript definitions in the future. Recommend switching over to TypeScript for this library so this file is generated automatically. :)
Coverage decreased (-0.2%) to 57.267% when pulling c609aea584a16eb6823f23c4575ba70839f44146 on MicahZoltu:master into b1a098a2c63f44b6a6ded2164cb47056ce0825f0 on ethereum:master.
I'm not sure it is a good idea to have forced description the JSON, it is not actually part of solc-js, but part of Solidity.
As a user, I depend on solcjs, not Solidity (I get that transitively). Therefore, I should be able to get the typescript definitions through solcjs. Specifically, I call functions in the solcjs library and it takes parameters/returns values that have a type and if I am using TypeScript those types should be exposed to me without needing to include some additional library.
I don't believe there is any easy way to bundle TypeScript definitions with Solidity such that I can get them transitively via solcjs, which is why I have added them here. I'm certainly open to other mechanisms for making the definition files available, but this seemed like the best option from a usability standpoint.
The two links you provided (@axic) in your comment how I created this file in the first place. If you believe I have mis-interpreted the documentation or there is otherwise an error in this definition I encourage you to point it out (please be specific). I have updated the PR with a couple changes for where I believe I had a mistake previously (non-optional fields), but the documentation is not particularly clear on what happens when a node in the object graph would be an empty array or empty object; will the node be omitted or will it be empty?
Examples of what is unclear are the top three keys (errors, sources, contracts) and contracts.[globalName].[contractName].evm, .ewasm, and .evm.bytecode. According to the documentation, these things cannot be filtered out, yet they may reasonably be empty based on filters and compilation results (e.g., no errors may be present, or all of the bytecode fields may be filtered out).
@MicahZoltu @danqing @cruhl sorry for the delays, we just need to understand Typescript better since otherwise we cannot maintain it and merging means we have to maintain it.
Would it be possible to add tests which use the typescript definition?
There isn't really a way to "test" definition files unless you author your actual tests in TypeScript (which I generally recommend, but is out of scope for this PR). It is a matter of whether the definition files line up with reality, and testing that means writing a test that tests actual functionality in TypeScript. If there is a mismatch, either the test will fail to compile or the test will fail.
Is this definition also relevant for the user with solc/wrapper?
I'm trying to match the definitions with the actual use or the code in the README.md. E.g. this line:
console.log(contractName + ': ' + output.contracts[contractName].bytecode)
But CompilerContracts doesn't have a field bytecode on top level.
https://github.com/ethereum/solc-js/blob/bab0fef1eae729610421344378bfcb0f65e152f3/index.d.ts#L112-L148
Last I checked contracts[contractName] doesn't have a bytecode field on it directly. Perhaps this has changed?
Looking at the Readme of the repository and the definitions I would assume it will not work. Also it did not work for me in a local project with this specific example.
As far as I know, the Typescript people write tests which work with their definitions and run the Typescript compiler on them. Could be an option.
At the point in time when I submitted this PR it worked. npm install solc and dump this in your project's definitions folder. This project compiles and runs: https://github.com/AugurProject/augur-core/blob/2d9cbac69e33be2f07a02ad91fe51574994be066/source/libraries/ContractCompiler.ts#L154
The definition file that project uses can be found here: https://github.com/AugurProject/augur-core/blob/master/typings/solc/index.d.ts
Uses solc 0.4.20
Is this still being worked on? Would love to have TypeScript definitions for solc-js!
I'm not actively working on it, but would still like to get it merged. I'm unclear if there is anything realistic that we could do to get this merged. To maintainers: Can you decide yay or nay on this rather than limbo? If you decide nay it can be added to DefinitelyTyped so people can still benefit (though not as cleanly).
The API with 0.5.0 changed significantly. It only supports strings externally and as a result there's no need to define the JSON (including ABI JSON).
@MicahZoltu can you update the PR? I'd like to merge it after.
To clarify: if you could create a PR which only adds types to the public methods on wrapper (e.g. without the standard JSON/ABI) that could be merged quickly. The rest of this PR is more complicated.
Hmm, I haven't followed Solidity 5.0, and I don't understand what you mean by "it only supports strings externally".
I have created ea new PR that only contains the compile callback definition: https://github.com/ethereum/solc-js/pull/298
While I'm happy to see that PR get merged as it is a good starting point for getting TypeScript definitions included, I don't feel that it is nearly as useful as getting the JSON input/output well defined.
I'm also curious why the compile function takes a string and returns a string when what it really wants/provides is a very specifically defined JSON object. In normal JS the difference is minimal, but in TypeScript the difference is pretty huge as you can get strong type checking and hinting if it takes a well defined object while "string" results in basically no type checking.
Hi, thank you very much for this PR. However, part of what was discussed here was already implemented or is under development in other PRs (e.g. https://github.com/ethereum/solc-js/pull/630), so I will be closing this for now.
Please, feel free to reopen it if necessary.
