Closed martyall closed 6 years ago
I don't see a major reason the generator needs to be a core part of the library. Given the way it's structured (i.e. a sort of super macro code generator) I think it's wise to leave it separate.
I also don't see a reason not to do a 1.0 release, besides maybe some tests for all API methods (e.g. I found that bug in getBlockByHash
the other day). Maybe that is a reasonable ticket for a 1.0 milestone. Otherwise error handling is probs only other crucial feature I can think of
I agree. From a separation of concerns standpoint, seems perfectly reasonable to have the generator be it's own repo. If the contract ABI format ever changes again, it shouldn't matter for purescript-web3, only the generator. This is how I see the concerns being categorized:
Ethereum JSON RPC <--> purescript-web3 Ethereum Contract ABI <---> purescript-web3-generator
I think i want to include this one though
https://github.com/f-o-a-m/purescript-web3-generator/issues/11
We're finding that the way the code gen tool works is awkward for working with uport, and this would at least guard us from making any assumptions about how the generated code will be used. This requires small library changes.
I like your suggestions in https://github.com/f-o-a-m/purescript-web3-generator/issues/11
I've made some more regarding using named records too; I think it would make code more readable.
the plan is to cut a release after the EthDenver hackathon as long as there are no major complaints there.
Sweet. Can't wait for the big refactor! (On my end)
@kejace @XertroV @cmditch
Once the error handling gets settled (in pr now), there are no major revisions or reorganizations planned for this library, only adding features that might be currently missing. This means it's probably safe to cut a 1.0 release. If anyone has anything that makes them think otherwise now is the time to mention in.
The only thing we have been toying with is to bring the generator in as part of the library itself, but theres no necessary reason to do this seeing as what we have currently works alright as part of the npm build step. Can anyone here make an argument for or against doing this?