Repository navigation
Active alternative look here #1754
Description
If you’re evaluating Lua/C++ binding libraries and still looking at sol2, it’s worth reassessing based on current project health and capabilities. Repo activity and issue backlog suggest low maintenance velocity.
🚀 LuaBridge3: actively evolving alternative
Actively maintained with ongoing fixes and improvements:
- Supports Lua 5.5 and Luau (not supported by sol2)
- Performance is competitive and improving, in several cases surpassing sol2
- Support for C++20 coroutines
co_awaitinto Luayieldback into C++
- Open to contributions, with responsive iteration cycle
👉 https://github.com/kunitoki/luabridge3
🔧 Tooling advantage: tsujikiri integrates with LuaBridge3
The ecosystem goes further with automated binding generation:
- libclang-based analyzer / transformer / generator
- Comparable in spirit to Qt’s Shiboken, but generic and extensible
- Enables:
- Automated bindings generation (luabridge3 support builtin)
- API surface versioning with automation major / minor version bumps suggestions
- Reduced manual glue code and maintenance cost
👉 https://github.com/kunitoki/tsujikiri
Hope you find this useful and can get some inspiration from it.
Activity
WangJinruie commentedon Jul 2, 2026
Hi, thanks for the detailed introduction of LuaBridge3!
I’m currently using EnTT (the C++ entity-component system) together with sol2 via entt-meets-sol2, and one thing I really rely on is EnTT’s meta system (runtime reflection for types, functions, etc.).
I wonder: does LuaBridge3 support EnTT’s meta system?
Or is there any way to expose EnTT-registered meta types/functions to Lua automatically with LuaBridge3?
Thanks in advance! 😊
kunitoki commentedon Jul 2, 2026
Hey! No at the moment there is no direct support for EnTT meta system, but it wouldn't be difficult to add on top of what LuaBridge3 offers, pretty much like what is possible with sol2.
davidchisnall commentedon Aug 18, 2026
Do you have any documentation on porting from sol2? For example, a bunch of your APIs seem to take a
lua_State. In Sol3, this is managed bysol::state, do I need to manually manage that (lifetime, loading built-in libraries, script loading, and so on) with the underlying C APIs with LuaBridge3?It looks as if working with shared pointers with LuaBridge3 requires some explicit handling, are there any plans to do what Sol3 does here? The LuaBridge3 approach looks a lot more error prone (in Sol3, I simply define a factory that returns a
std::shared_ptr<T>for my usertype and it all Just Works™. Similarly, methods that return shared pointers for interior references don't require me to trace the entire object graph and make sure that I have subclassedstd::enable_shared_from_this.