search

nix-community / nixvim

Configure Neovim with Nix! [maintainers=@GaetanLepage, @traxys, @mattsturgeon, @khaneliman]
https://nix-community.github.io/nixvim
MIT License
1.75k stars 266 forks source link

Deprecate strLua types/option helpers #2003

Open MattSturgeon opened 2 months ago

MattSturgeon commented 2 months ago

Why

The biggest issue with types/options that transform the value is that once implemented, we are stuck with it lest we break users configs that rely on the transformation.

The other issue is that the transformation is somewhat hidden, meaning users end up defining a config in nix that is subtly different from the lua we end up producing.

Neither of these are an issue for "normal" module options, but for rfc42 style options such as settings it is not ideal.

How

We can deprecate passing strings directly using transitionType coercion. Similar to extraFiles, we would need a transition period before eventually removing support for string definitions.

When

We should update internal uses before having a deprecation warning.

Even if we don't want to deprecate yet, replacing the option apply implementation with a coercedTo type would be a good refactor IMO.

We should consider moving to nixpkg's lib.generators.mkLuaInline too, before asking users to change their configs. See #1935

MattSturgeon commented 2 months ago

@nix-community/nixvim any thoughts on a plan here? I think we should go down the strLua = coercedTo str mkRaw rawLua route, and start using __raw in our defaults/examples.

However I'm hesitant to make this change if we're soon going to start recommending lib.generators.mkInlineLua instead of lib.nixvim.mkRaw (#1935). It's possible we'd instead want coercedTo str mkInlineLua inlineLuaType?

I think we should decide this soon, since as this decision is currently blocking #2007.

khaneliman commented 2 months ago

I would be in favor of just transitioning to the new type mentioned in #1935 instead of spending time with rawLua if we will transition away from it soon.