feat(core): If a plugin is not enabled, ignore all specs in its dependencies

[abeldekat]

Example scenario:

return {
  {
    "A",
    opts = {
      foo = true,
    },
  },
  {
    "B",
    enabled = false,
    dependencies = {
      {
        "A",
        keys = {
          { "<leader>ab", function() require("A").needing_B() end, desc = "AB" }
        }
        opts = {
          bar = true,
        },
      },
    },
  },
}

Plugin B is disabled.
However, both definitions of A are merged into the final A:

• A.opts == { foo = true, bar = true }
• key <leader>ab is present, and will fail when invoked, on the absence of B.

Note that currently, when A would only exist as a dependency of B, plugin A would have been disabled as well.

The configuration of a plugin can depend on the presence of another plugin.
A good example is the conditional definition of a key.
Currently, extra code is required, checking for the presence of a plugin using programmatic "guards".

This PR ensures that plugin A only contains the definition provided by plugin B, if B is enabled.
The result becomes:

• A.opts == { foo = true }
• key <leader>ab is not available.

An opinion on the benefits

• it's easier to configure specs on a need to have basis
• specs are easier to reason about

An opinion on the implications

This PR will most likely not break existing personal configurations.
Users might have expected the behaviour this PR aims for to already be in effect.

Distributions however are highly modularized by nature. Maintainers are advised to inspect the code.
Consider a definition of A inside B, containing a property that should always be present on A regardless of the status of B.

Breaking example:

return {
  {
    "A",
    opts = {
      foo = true,
    },
  },
  {
    "B",
    enabled = false,
    dependencies = {
      {
        "A",
        opts = {
          ALWAYS_NEEDED = true, -- BREAKING, not present anymore!
        },
      },
    },
  },
}

In this case, it would make sense to move the configuration of property ALWAYS_NEEDED to the top-level spec of plugin A.

Approach

This PR changes the Plugin.parse method, after all specs have been normalized.
An enabled plugin will be repaired when it contains a spec originating from the dependencies property of a plugin that is not enabled.

The enabled plugin can be repaired by redoing its merge operation, using a filter on its individual plugin definitions.

I did not observe a noticeable decline in performance.
When the user disables many plugins that have specs in their dependencies, some performance overhead is expected.

Additional context

AstroNvim's lead developer proposed the idea in this discussion. Thanks @mehalter, for all the support!

A scenario illustrating the effect of the proposed changes is discussed in the code review of the following PR: enable telescope extension of nvim-notify.

Worth mentioning: An explanation on how dependencies are loaded, written by Folke in this issue.

While investigating existing issues, I found an issue from @UtkarshVerma, also addressing the topic: Don't process dependencies if spec is disabled.

[folke]

Fixed by #1058