Ahh, sorry for the bad url, I meant https://www.npmjs.com/.
I didn't mention luvit.io/lit.html because it didn't exist at the time. I agree that high-level API docs and examples would be the most useful along with basic description. I've considered adding a field to the package metadata called "documentation" pointing to a markdown file in the package or "examples" pointing to a lua file. Also as a fallback I could look for a README near the homepage, but then I'm scraping github which has rate limits and could be problematic. As much as I want to keep lit packages small in sice, I think it's useful to have some basic docs in the package. How about having a tri mode property for "documentation". If the value is a valid url, hyperlink to that external resource. If it's the path to a file in the package, render it inline. As a fallback, assume the content is the data. Some examples to show what I mean: documentation = "http://mysite.org/docs.html"; -- Link to external resource documentation = "README.md" -- link to internal file in bundle documentation = [[ # My package Here is my documentation! ]] -- inline markdown, useful for single-file packages. On Tue, May 5, 2015 at 1:39 PM, Lionel Duboeuf <[email protected]> wrote: > > That's a nice needed feature and well designed. Of course the best for me > would be to have a quick overview of exposed functions and access to > samples. i've noticed that new metadata allow us to add git repository link > of the library. So maybe with a common repo architecture, it will be easy > to find samples/examples directory and docs. > > Something wrong with "npm.org" url ;-), maybe you were talking about > http://npmsearch.com ? > You didn't mentioned https://luvit.io/lit.html url in order to test > search within luvit.io site. > > regards > Lionel > > > Le mardi 28 avril 2015 22:25:33 UTC+2, Tim Caswell a écrit : >> >> Many of you have asked for some sort of search functionality in the >> public lit database so you can see what luvit/lit modules are already out >> there. >> >> I'm making progress towards this being as nice as what's at npm.org. >> >> If you're running the latest lit client, then new packages you publish >> will have extra metadata stored in the git tag making it accessible to my >> server to find. >> >> Also today I deployed a new lit server to lit.luvit.io that has a new >> search command in the API. >> >> Check out the following sample queries to see what the results look like >> (I recommend having the jsonview extension in your browser) >> >> https://lit.luvit.io/search/msgpack >> https://lit.luvit.io/search/coro >> https://lit.luvit.io/search/weblit >> https://lit.luvit.io/search/luvit >> https://lit.luvit.io/search/virgo >> >> Currently it only matches against package names or author names and >> includes both in the results. If it is a package it pulls out some >> metadata, especially in newer packages since the lit client update. >> >> Let me know what you think, and anyone with web-dev experience is welcome >> to try their hand at a HTML+JS frontend. I can host it at luvit.io if >> you wish or add CORS headers to the REST calls so your client can be hosted >> anywhere. >> >> -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. > -- 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.
