solc-js
solc-js copied to clipboard
ethereum
Feature Request: pull wrapper out of solc-js
It would be nice if solc/wrapper were pulled out of solc-js and made into it's own dependency. 🙏
Hey @axic I'll jump in here.
Basically, we want to remove the NPM solc dependency from Truffle, since it's required a lot of dedicated effort over the years, and now we have a separate mechanism for fetching soljson files and making sure they work portably. (See trufflesuite/truffle#2034 for more information.)
The one thing that is out of our control, preventing us from decoupling from NPM-solc, is the wrapper. As you probably recall, you suggested we use the real solc wrapper instead of rolling our own. Of course this is the way to go (why duplicate that file?), but it'd be nice if we could get just the wrapper instead of require()ing all of solc-js.
The benefit here is that there would be a separate, isolated component to do a separate, isolated thing. You could continue to expose solc/wrapper, and use it in that form internally in this project, but have the implementation live in its own place.
I ran into a similar issue, and ended up forking solc-js just to remove the asm. It'd be great to have an official package with this. I can transfer ownership of the solc-wrapper npm package name if you are open to this.
I ran into a similar issue, and ended up forking solc-js just to remove the asm.
Still confused what was removed?
Still confused what was removed?
The latest version of the compiler from inside the package, so it is just the wrapper.
But that shouldn't be included through packaging when the dependent package uses var solc= require('solc/wrapper).
If it is, that must be an issue of the packaging system.
It is not loaded, but it is shipped with the package, which makes it several mbs heavier:
$ du -sh node_modules/sol*
14M node_modules/solc
56K node_modules/solc-wrapper
You mean shipped on a node installation, but at least it doesn't affect webpack?
We are not (yet) webpacking zOS, so I wouldn't know. @gnidan you do run the truffle CLI through webpack: does it affect bundle size? Or is this just a matter of separation of concerns (which IMO should be a good enough to remove the binary from this package)?
As we've discussed above webpack is not affected.
I'd like to also separate things, but it is not that simple and can become even worse if done recklessly. Either we end up having a dozen of packages which are hard to maintain or we need to wait for a breaking release to time the changes with.
I'll confirm that webpack is smart enough not to bundle the asm if you only require the wrapper. We opened this issue originally not knowing that, and also thinking there should be separation of concerns, but the latter reason is not as important to us.
@axic if you wanted, you could use lerna to make this a monorepo. We've found that this greatly reduces the operational complexity of managing a bunch of packages. Happy to expand on this if you're curious.
I'm not sure if there is need to get lerna in here yet. We're talking about just moving the wrapper code (which, as far as I understand, doesn't change too often) to a separate project, and have solc depend on it.
Anyway, given that this is just a matter of separation of concerns and polishing, not sure if it has much prio.