Adding a custom library

[vaintrub]

Hello colleagues!

Tell me, please, is it possible to add our library to your extension in meta/3rd? 😄
I represent the tarantool team, we have a lot of different modules and it would be really cool to have some documentation for them.

[flrgh]

Ahoy 👋 I can't think of any reason the maintainer would say no to such a PR. For instance, the LFS type defs were just added a couple months ago. Personally, I'm thrilled when I see anyone contributing to the type definition efforts, because it can be pretty tedious work, but once it's done we all reap the benefits. :)

[carsakiller]

Perhaps this is a good time to think about how the community can share the growing collection of definition files. There is a thread here for sharing definitions, but a thread isn't really the best medium for sharing libraries.

Realistically, not every library/API/framework can have its documentation included in the source code of this project. It would slow down the server and make the size needlessly large. Not to mention that many of the included definitions files would likely go unused and would serve as useless bloat — for example, I have never used any of the already included definitions.

I think it would be wise to set up a repository specifically meant for collecting definition files and libraries for this language server. This could simply be separate projects included as submodules. Alternatively, the community could collaborate as a whole, opening PRs directly on that repository and documenting things as a team, similar to DefinitelyTyped for TypeScript.

An idea I had is to create a simple GitHub Pages webpage that would allow visitors to browse through the various definition projects and get directed to the corresponding repositories for them. This way, there is a central location to help everyone find the definitions they are looking for. This sounds like a fun project that I would have no problem getting started on 😄.

As always, open to feedback/ideas, especially from @sumneko as this is your project 🙂

[flrgh]

Mostly just brainstorming here, but what if the existing /meta/3rd directory was moved into another repository, which was in turn included in the default set of type definition sources/collections:

{
  type_definition_sources = {
    -- contains all the current type defs for OpenResty, lfs, lovr, etc
    "git://github.com/sumneko/lua-type-annotations.git"
  }
}

The language server fetches the content and performs the library detection logic for each library/directory found therein, and every once in a while it checks to see if any of them need to be updated. Anyone can publish type defs or type def "collections" on github, and we can curate+index the good ones in the wiki.

A final configuration might look like...

{
  type_definition_sources = {
    "git://github.com/sumneko/lua-type-annotations.git",
    "git://github.com/flrgh/additional-lua-type-defs.git",
    "git://github.com/carsakiller/massive-collection-of-common-lua-type-defs.git",
    "file:///path/to/local/type-defs/directory",
  }
}

I think we should still strive to have as many commonly-used libraries/frameworks in the "central" type definition repository because that will lead to the best UX for new users, but this structure would lower the barrier for users to import/use type definitions from smaller projects without having to manually download something and add it to Lua.workspace.library.

[Frityet]

This should also be bailable for plugins

[serg3295]

Perhaps it makes sense to give the user the opportunity to choose which libraries to download.
The extension will support a curated list of user repositories, and the user will download the repositories he needs himself.
A similar logic of work is implemented in the mason.nvim plugin for Neovim. But instead of language servers, type definition repositories will be used.

[carsakiller]

I don't have the time right now to make this too pretty - but I was thinking we could maybe use a webview to list available "addons", as well as the installed ones. This would integrate really nicely with VS Code.

This would of course also require another solution for NeoVim though.

[carsakiller]

Discuss further over in #1607