Luvit 2.0 has been stable for a while now, the refactor to split into luv, luvi, and luvit was a great success. Now it seems the major issues are around documentation and what's legacy support and what people should be using for new projects.
There are two competing interests currently. 1. Large legacy projects that use luvit in production and depend on the node.js style libraries as well as the exact semantics of the original luvit 1.0 require system (that replaces lua's require). 2. New luvit projects that want a clean start and are confused about the strange behavior or the luvit 1.0 require (hint, I didn't know lua very well when I designed it). I propose we republish the current luvit system as `luvit-node` or something to signify that it's a node.js clone in lua. Then with the main `luvit` namespace free, we can publish `[email protected]` which uses the new luvit-loader require logic the same as lit. We can also remove all non-essential libraries to make this core less opinionated. Basically the idea is to take https://github.com/squeek502/luver and make it the main `luvit` that is the base everything else builds on top of. (we'll still have the raw luvi option for people wishing to make single-binary applications as well) what do you all think? -Tim Caswell -- You received this message because you are subscribed to the Google Groups "luvit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
