What's the right way to configure leptosfmt to work with Lunarvim?

Question

I'm trying to configure leptosfmt to work with Lunarvim, so that I can format my view! macros on save. I've not yet found a clean working solution. Here's what I've found and tried:

Based on the readme and this pull request in the leptosfmt repo, I've tried applying the same configuration to the Lunarvim LSP config:

require("lvim.lsp.manager").setup("rust_analyzer", {
  settings = {
    ["rust_analyzer"] = {
      rustfmt = {
        overrideCommand = { "leptosfmt", "--stdin", "--rustfmt" },
      }
    }
  }
})

However, this does not work - the view! macros do not format on save as expected.

I'm also using Rust Tools, and I tried using the same pattern in that configuration:

        server = {
          on_init = require("lvim.lsp").common_on_init,
          on_attach = function(client, bufnr)
            require("lvim.lsp").common_on_attach(client, bufnr)
            local rt = require("rust-tools")
            -- Hover actions
            vim.keymap.set("n", "<C-space>", rt.hover_actions.hover_actions, { buffer = bufnr })
            -- Code action groups
            vim.keymap.set("n", "<leader>lA", rt.code_action_group.code_action_group, { buffer = bufnr })
          end,
          settings = {
            ["rust_analyzer"] = {
              rustfmt = {
                overrideCommand = { "leptosfmt", "--stdin", "--rustfmt" },
              }
            }
          }
        },

But that also appears to have no effect. I also tried uninstalling rust-tools to ensure it wasn't conflicting with Lunarvim's LSP setup process with the first option. No luck.

I did manage to write this workaround that "works":

vim.api.nvim_create_autocmd("BufWritePost", {
  pattern = "*.rs",
  callback = function()
    local found = vim.fn.search("view!", "nw")
    if found > 0 then
      local filepath = vim.fn.expand('%:p')
      vim.fn.system('leptosfmt ' .. filepath)
      vim.cmd('edit!')
    end
  end
})

But I can't help but think that's probably the wrong way to handle this and likely has performance implications.

Any more suggestions?