Skip to content

feat(rust): bump rustaceanvim to v8+#1755

Open
rami3l wants to merge 1 commit intoAstroNvim:mainfrom
rami3l:feat/bump-rustaceanvim
Open

feat(rust): bump rustaceanvim to v8+#1755
rami3l wants to merge 1 commit intoAstroNvim:mainfrom
rami3l:feat/bump-rustaceanvim

Conversation

@rami3l
Copy link
Copy Markdown
Contributor

@rami3l rami3l commented Apr 11, 2026

📑 Description

Based on #1753 and #1754, as promised :)

This PR bumps rustaceanvim to v9 on Neovim v0.12+, and to v8 on Neovim v0.11.

Tested locally with first this override (daily-driving) and then a local dir override on astrocommunity.

📖 Additional Information

One major difference from the current v6 here is that the sharing of project-local configs with VSCode has been outsourced to an external plugin codesettings.nvim.

Considering the fact that it might not be relevant to everyone I'm leaving the config under a pcall guard.

However, it might still be interesting to include it in the pack here (as an optional dependency or something?), or it can be made into its own recipe later on.

cc @Uzaaft

@github-actions
Copy link
Copy Markdown

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

  • If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

  • If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

  • Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

  • README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

  • Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

  • Proper usage of opts table rather than setting things up with the config function.

  • Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant