You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
@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.
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.
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 toextraFiles
, 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 acoercedTo
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 #1935The text was updated successfully, but these errors were encountered: