But what about lit and luarocks? As I understand luvit will use native requires?
> 26 сент. 2016 г., в 23:06, Tim Caswell <[email protected]> написал(а): > > 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. -- 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.
