Closed mikavilpas closed 3 months ago
Also related https://github.com/vhyrro/luarocks.nvim/issues/12, if lua specifc instructions are deemed necessary, a workaround could be added to this issue (I don't know what one would be right now)
Hey again :smile:
I'm not sure what the status in the neovim plugin ecosystem is on using luarocks, so that's why I picked lazy.nvim because it can work with everything (including specific git branches, tags, commits etc).
Typically, if a plugin isn't on luarocks, I
Another option is to add a rockspec and use luarocks install <path-to-rockspec>
to install it directly from the rockspec (in this case, it doesn't have to be on luarocks).
Do you think it could be highlighted so that it's easier to see? Currently it is the second item.
I think nlua
will be the easiest tool to use for most people, so maybe an example project and some documentation on how to set up a GitHub Action in the nlua
readme is the way to go.
I think it would be very effective to have a list of concrete actions on how busted should be set up
This, too, is probably better kept in the busted
or nlua
documentation.
how should I structure my project's tests?
I would rather see this in the busted
docs. It's out of scope for this guide.
Is nlua required? Do I need it, or can I just get started with neovim instead?
Not strictly. It just makes it more convenient, because it translates Lua's CLI to Neovim's.
Also related vhyrro/luarocks.nvim#12, if lua specifc instructions are deemed necessary, a workaround could be added to this issue (I don't know what one would be right now)
In principle, the lua version used with the luarocks installation shouldn't matter. luajit and lua 5.1 are mostly compatible with one another.
For future reference, I finally did the conversion in my project. The change can be found here https://github.com/mikavilpas/yazi.nvim/pull/113 (in case technical details might be useful for others)
Really happy with the results, by the way! šš»
I'm spending some time going through the suggestions in the testing section. I think the recommendation to move from
plenary.test
to busted sounds good, and it doesn't seem too complicated since it's apparently a superset of what my plugin is already using.I also love the recommendation on using luarocks. I built my own hacky system that uses lazy.nvim to set up tests (it uses its own
lazy-lock.json
that I commit to the repository), but I will see if I can move to using luarocks instead.I'm not sure what the status in the neovim plugin ecosystem is on using luarocks, so that's why I picked lazy.nvim because it can work with everything (including specific git branches, tags, commits etc).
I'm looking for clarification on a few things that might also be good candidates to add to the guide if you feel like it:
As a plugin author, https://mrcjkb.dev/posts/2023-06-06-luarocks-test.html seems like a short and "to the point" guide. Do you think it could be highlighted so that it's easier to see? Currently it is the second item.
The instruction to
...use [busted](https://github.com/lunarmodules/busted) for testing, which is a lot more powerful.
is good, but it's a bit of reading š ... I think it would be very effective to have a list of concrete actions on how busted should be set up:as a beginner plugin author, what programs should I install to get started?
how should I structure my project's tests? This PlenaryBusted guide is very succinct and helpful in this regard.
Is nlua required? Do I need it, or can I just get started with neovim instead?