There's a bit of a bootstrapping problem with the llhttp-ffi dependency:
Whenever upstream (llhttp) is updated, a new llhttp-ffi release (or at least commit) is needed to pull in the update here
Before an llhttp-ffi release (or even regular PR) can be published, the tests need to pass
The tests rely on downloading the latest release of the runtime (this could be changed to use LuaJIT, I guess?)
This release of course includes the previous version of llhttp-ffi, which also must be loaded (= llhttp.cdefs is loaded)
Once the C definitions have been loaded, there's no way to replace them inside LuaJIT (that I can see), or undefine them
As a result, llhttp-ffi can't "properly" be updated and any attempt at circumventing the chicken-and-egg problem gets hacky fast.
I think it makes the most sense to just pull in the ffi bindings and add llhttp itself as a submodule here. It's not like anyone else would be likely to use them, and there's even another library now that binds llhttp for both Lua and LuaJIT. There may be some way to make it work, but honestly it isn't worth the hassle for such a tiny Lua module.
There's a bit of a bootstrapping problem with the llhttp-ffi dependency:
llhttp-ffi, which also must be loaded (=llhttp.cdefsis loaded)As a result, llhttp-ffi can't "properly" be updated and any attempt at circumventing the chicken-and-egg problem gets hacky fast.
I think it makes the most sense to just pull in the ffi bindings and add llhttp itself as a submodule here. It's not like anyone else would be likely to use them, and there's even another library now that binds llhttp for both Lua and LuaJIT. There may be some way to make it work, but honestly it isn't worth the hassle for such a tiny Lua module.