Move capnp module implementation workerd #5070
Conversation
|
It would be good to understand the motivations and background here further. What is the maintenance approach being taken - to allow divergence? Is there a sync process? Or are there plans to evolve this further as well? |
|
Given it declares a custom TypeWrapper, one could argue this belongs under JSG rather than API. |
The goal here is to work towards consolidating as much of the module registry implementation as possible within workerd. Right now, between workerd and the internal project we end up with a fair amount of duplicated code, as part of the new module registry work, I'm working towards consolidating that. There is no sync process, this is being moved from internal to workerd, it's not going to exist in both places.
Yeah, I was considering that also. ...Actually, tho, I think for now keeping it in api is appropriate. The implementation has a dependency on the IoContext in several places and nothing in jsg is IoContext aware. |
8e60da4 to
aea252f
Compare
1798d0b to
d735f22
Compare
f6ac855 to
f558392
Compare
Moves the capnp module implementation out from the internal project to workerd.
This is part of the new module registry consolidation effort.
No changes were made to the
api/capnp.handapi/capnp.c++files other than changing the namespace name. Those were duplicated directly from the internal projectthis builds on #5065 which must land first