What do you mean "only in current shape"? I won't be changing any of the APIs and the current set of APIs in the 'luvit' package will still be available. They will just require being included in your app's dependencies the same as any other non-core dependencies. The newly renamed `luvit-node` metapackage will still pull in the entire luvit 2.x standard library. So at most, you'll need to add a single line to your package.lua to migrate to luvit 3.0 from luvit 2.0.
Also with a reduced scope in the core and switching to a saner require system, I'll have more time and ability for actually writing docs. On Mon, Sep 26, 2016 at 3:03 PM, Dmitri Voronianski < [email protected]> wrote: > Hi, > > I recently started to update my luvit packages to luvit 2.0 - > https://github.com/luvitrocks/ as well as writing API in luvit. As for me > it will nice to have luvit and lit stable and add more features to them. I > think lit and luvit will be more successful only in current shape. > > 2016-09-26 21:17 GMT+02:00 Tim Caswell <[email protected]>: > >> 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. >> > > > > -- > Best regards, > > *Dmitri Voronianski* > > -- > 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. > -- 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.
