notice: status of the project

[NTBBloodbath]

Hey, it's been a while since the last time I did feel interest in rest.nvim due to some motives I'll listen below.

However, I'll first tell y'all what's going to happen with the project, will i keep maintaining it, etc.

The project has been very abandoned lately, and when I wanted to keep it I've been procrastinating on other things and in the end I completely forgot (what a shame). It's a great plugin, and it may have even more potential than it already has (many thanks to all contributors, even the ones that doesn't contribute with code but bug reports and such stuff), I think it's time for its development to move forward, however, there are many bugs that I cannot fix since they are somewhat specific to certain use cases and I cannot reproduce them to be able to debug and do TDD until I fix them (this is why I lost some interest in the past).

I was currently on vacation and traveling for a couple of weeks and will only be back home early next week (it's still Sunday here) so in case of resuming development it would be when I return home. There are some PRs that I need to review, some issues that I'm sure I can fix myself and some feature requests that are useful and needs my attention, so that's where I'm going to start.

I sincerely apologize for the temporary abandonment of the project, and for not having merged many of your contributions to the project during all this time and also not fixing current project issues, little by little I will be taking up the project again in its entirety.

Cheers,
Alejandro

[NTBBloodbath]

Small update: I have already enabled linter checks on first-contribution PRs, I'll try to keep a eye on them in case one of the PRs checks fails so I can let you know if there's something wrong with the source code.

[NTBBloodbath]

New update: as you can probably notice, rest.nvim and tree-sitter http parser repos have been moved to an organization. This will allow to have more contributors/maintainers to help merge patches and manage issues in the plugin.

README will be updated accordingly to the new URL changes to reflect them.

[NTBBloodbath]

New update: I'll probably start a rewrite today so I'll not merge any new or existing PR as it's going to cause A LOT of merging conflicts and make rewrite harder.

However, I'll probably adapt the PRs changes to the new codebase and add their authors as Co-authors so they'll still get credits for their contributions in the repository Git history.

This rewrite is going to take a few days or weeks depending on my free time so I'll post any new thing here just in case someone wants to track current rewrite progress.

One of our goals is to ditch plenary's cURL wrapper and adopt a libcURL wrapper from luarocks so we can get a more powerful and less error-prone http client.

[teto]

I wonder how advanced is that rewrite and what place there is around api design ? For instance what are the goals of the rewrite ?
I would prefer to iterate on what we have rather than a full rewrite. While working on tests, the annoying part is parsing the file, your comment here #136 (comment) looks interesting. Experimenting with teal could be interesting too as I find writing lua tedious without type info.

[NTBBloodbath]

I wonder how advanced is that rewrite and what place there is around api design ? For instance what are the goals of the rewrite ?

There is no much codebase progress at the moment, I've been somewhat occupied very lately but there is a WIP specs file too that I'm constantly feeding.

The benefits and goals of the rewrite are mostly changes to the default features of rest.nvim (I love loading only what I truly need, for example), using tree-sitter parser as a first-class citizen to parse http requests AND get a more powerful and stable cURL wrapper (this one is huh a bit difficult as packer codebase rewrite removed luarocks support and other plugins managers doesn't support luarocks so I'm looking for possible solutions).

I would prefer to iterate on what we have rather than a full rewrite. While working on tests, the annoying part is parsing the file, your comment here #136 (comment) looks interesting. Experimenting with teal could be interesting too as I find writing lua tedious without type info.

Yeah I'll probably not rewrite everything and rewrite is going to be incremental so I'll probably just refactor some things and remove code that we don't really need at this point (this was my first plugin and my experience with Lua wasn't the best at that time :p), however there are some things that are worth rewriting from scratch.

Parsing requests using tree-sitter should make the process way easier and friendly in general (I really hope it's going to make tests more enjoyable to work with).

About Teal hmm I really don't know if it's worth it. In my experience, Teal doesn't do anything to keep codebase "type safe" (not even an if type(foo) == bar then ... end) when compiling it to Lua so it's like a better experience during development but production is exactly the same. Also we would need to grab types for Neovim Lua API somewhere, that's not a huge problem tho as lewis (gitsigns maintainer) use Teal so he should have a huge types definition file.

[teto]

Parsing requests using tree-sitter should make the process way easier and friendly in general (I really hope it's going to make tests more enjoyable to work with).

I've been modifying the grammar and the plugin to use tree-sitter. I already have sthg working and it's very powerful. It makes debugging a lot easier since we can identify errors and matches through the treesitter tree. There is no more need to move the cursor and search for text, then restore the cursor. One can ask the number of requests, all the requests in a file, so possibly those could be run in parallel etc. I will ask for feedback once it's ready probably next week.

About Teal hmm I really don't know if it's worth it. In my experience,

I've quickly played with fennel and teal and none has really impressed me so far. I am not sure the type safety brought by teal is worth the overhead. I am still interested in trying it out though but once we use treesitter, I think it will simplify the codebase a lot and thus typesafety becomes lesss relevant (especially as we improve tests).

[NTBBloodbath]

After a very long hiatus, I think it is time to give rest.nvim the proper maintenance it deserves. I can't give an ETA, but I will be dedicating most of my free time to the project.

I had completely forgotten that this issue was locked. I've already unlocked it so anyone who wants to contribute to the project can let me know here or find me on Discord or Matrix with the username ntbbloodbath and I will try to reply as soon as I can.

Cheers

[NTBBloodbath]

Small update: I made a room in Matrix, anyone who wants to join is welcome and can do so by clicking the Matrix badge in the project README!

[NTBBloodbath]

Small update: the rewrite is going well, I hope soon to push the changes to the tree-sitter parser and then start pushing some code to the development branch (please don't use it, it will be broken for a while due to constant changes and new dependencies) and also give some updates on my blog with a few gifs of the new plugin performance.

In the meantime, if you could vote on #272 it would be of great help to me :)

[NTBBloodbath]

Update: finally, parsing with tree-sitter is coming!

The changes are already pushed to the next branch of the parser repository. The parser has grown about 44kB in weight (it's 124kB now) because some rest.nvim functionalities have also been included that for some reason had been passed in the parser, however, the performance has not been negatively affected in the time of use that I have given it.

However, I had to make a breaking change in the syntax of the script variables to avoid false errors due to tree-sitter injections. The change is pretty small and just a few adjustments so don't be afraid of it (for real, it's just adding -- at the start of the {% and %} delimiters lol)!

The parser is fully functional with the current version of rest.nvim, however, it obviously doesn't do us much good. If you want to test it and report a bug if you find it, you can do so by changing the parser branch in your nvim-treesitter configuration then reinstall the parser through :TSInstall http and entering y in the reinstallation prompt:

local parser_config = require("nvim-treesitter.parsers").get_parser_configs()

parser_config.http = vim.tbl_deep_extend("force", parser_config.http, {
  install_info = { branch = "next" },
})

[NTBBloodbath]

The dev branch is almost ready for an MVP release of v2 of rest.nvim. Things that are missing for that to happen:

• Luarocks and dependencies handler (check if any of them is missing, provide install instructions, etc). Implemented through a :checkhealth rest-nvim command
• Form data support (WIP)
• Proper Host header parsing
• Re-implement legacy <Plug> keybinds to at least not break users' existing keybinds and add a deprecation notification for them to migrate over to the :Rest command
• Fix releases CI for dev branch and the lua-curl dependency

---

Edit: in case anyone wants a preview of the brand new :checkhealth rest-nvim window, hope it will be helpful enough for everyone to troubleshoot their rest.nvim installation :)