Split types to a seperate repo/ npm package

[sigmaSd]

Hello, thanks for this nice project!

I think the types are useful for everyone writing nvim plugins with typescript and it would be great if you can split them so it can have its own development and contributions. ( I already started adding stuff I'm using )

[jose-elias-alvarez]

This is a good idea! I've found it surprisingly ergonomic to write Neovim plugins in TypeScript, but there are a lot of gotchas involving the compiler, so making it easier for everyone would be great (I've been meaning to put together an example repo once I can figure out a couple of lingering issues, too).

One issue that I can think of is maintenance - the Neovim API is pretty large and constantly changing, plus release versions don't necessarily match HEAD - but in the meantime we can get started with what I have here + user contributions. I'll see what I can put together.

[sigmaSd]

We should start from somewhere and what you have is already a good start , I think it would be a good idea to point somewhere to a minimal plugin as example or template.

I'm still trying it but it feels like typescript become a superset of lua, or I'm writing lua with types, so far I think the idea is really good !

One thing to think about is maybe autogeneration, for example denops does this I think https://github.com/vim-denops/deno-denops-std/blob/main/scripts/gen-function/gen-function.ts

[sigmaSd]

I tried earlier today a prototype example https://github.com/sigmaSd/nvim-ts-demo

One immediate gotcha I faced was noImplicitSelf, that probably need to be documented somewhere in your example about why its needed

[jose-elias-alvarez]

Great, thanks! I will take a closer look as soon as I have time.

[jose-elias-alvarez]

I apologize for my lack of attention here. I've been meaning to split up the type definitions into a separate repo, create an example repo, and write an article about TypeScript as a Neovim plugin language, but I've gotten hung up on the TSTL compiler's incompatibility with Neovim's require path resolution (which among other things raises startup time, making it a no-go for some of the community).

I opened TypeScriptToLua/TypeScriptToLua#1371 to see if there's an existing way to resolve the incompatibility (or if there's any interest in adding one). Once that's resolved one way or another, I'll see how I want to proceed. For example, if I end up writing a script to find and modify require paths, it may make sense to create a template including this script.

[lougreenwood]

This sounds very exciting - I was just reading the above issue about import paths and learning about TypescriptToLua for the first time.

Suddenly with this project, writing nvim plugins becomes accessible to so many more people (and even helps to passively teach lua to us TS devs by seeing the side by side transpiration!)

[sigmaSd]

I published the types on my own npm package for now https://github.com/sigmaSd/nvim-types https://www.npmjs.com/package/@sigmasd/nvim-types

Its scoped under my username, so I can deprecate it when you decide to publish the npm pacakge

This will allow me to test things and push types I'm using already for my config and plugins,
Already setting things up required a lot of debugging (but that's probably because I'm not familiar with tsc/npm)

[sigmaSd]

I found https://github.com/gkzhb/lua-types-nvim which seem to be advanced