# fyler.nvim: a file manager you edit like a Neovim buffer

> fyler.nvim is an oil.nvim inspired Neovim file manager that manipulates the file system the way you would edit a buffer, while presenting items as a proper file tree. It needs Neovim 0.11 or later, installs through lazy.nvim, mini.deps or vim.pack, and ships a headless test harness built on stylua, selene and nvim.

**FylerOrg/fyler.nvim** — A neovim file manager which can edit file system like a buffer with tree view

- Repository: https://github.com/FylerOrg/fyler.nvim
- Stars: 772 · Forks: 55
- Language: Lua
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/fylerorg-fyler-nvim

## The file system as an editable buffer

Fyler.nvim is a Neovim file manager which can edit file system like a buffer with tree view. The README describes it as an oil.nvim inspired file manager plugin for Neovim which can manipulate file system like a Neovim buffer and provide a proper file-tree representation of items.

That description contains the design in two halves, and they pull in different directions on purpose. The buffer half is what makes the plugin feel different: rename an entry and you are editing a line, delete one and you are editing a line, and the motions and operators you already know apply. The tree half is what keeps the result legible, because a flat list of full paths gets hard to read once directories nest.

The requirement is Neovim >= 0.11, which is the version floor to check first. It is a high floor relative to the wider plugin ecosystem, and it means the plugin is aimed at people running a current Neovim rather than a distribution packaged version.

The credits list is also a statement of position. GrugFar, Mini.files, Neo-tree, Neogit, Nvim-window-picker, Oil, Snacks and Telescope are all named, which places the plugin in a family of Neovim file management rather than presenting it as an unrelated invention. Oil in particular is named as the inspiration, and the plugin's topic tags include telescope-extension.

## Three installation paths, one dependency line

The plugin can be installed with the three managers most Neovim users now have, and the README gives one line for each.

With lazy.nvim, the specification is the shortest of the three:

```lua
{ 'FylerOrg/fyler.nvim', opts = {} }
```

With mini.deps, the plugin is added imperatively:

```lua
require('mini.deps').add('FylerOrg/fyler.nvim')
```

And with the built-in vim.pack mechanism:

```lua
vim.pack.add({ 'https://github.com/FylerOrg/fyler.nvim' })
```

The fact that all three are supported in the README is itself informative about the current state of the Neovim plugin ecosystem, where a plugin that supports only one manager is now an exception. The opts = {} in the lazy.nvim example is the place where configuration would go.

For the deeper material, the README points to the built in help with :help fyler.nvim, or to the wiki pages for more detailed explanation and a live gallery. For a plugin whose main idea is a new way of interacting, the wiki is where the interaction model is going to be explained, so it is the right thing to read before installing rather than after.

## Opening the finder from the command line and from Lua

The plugin is opened with the :Fyler command, and the README lists three forms of it. Plain :Fyler opens the finder, :Fyler root_path=<path> uses a different directory path, and :Fyler kind=<buffer_kind> opens a specified kind directly.

The Lua API mirrors that. The module is required as fyler, fyler.open() opens using defaults, fyler.open({ kind = "split_left_most" }) opens as a left most split, and fyler.open({ root_path = "~" }) opens with a different directory.

The README also shows how to wire it to a key, and the two examples are worth reading together because they differ in a way that matters. The first maps the function directly:

```lua
vim.keymap.set("n", "<leader>e", fyler.open, { desc = "Fyler.nvim - Open" })
```

The second wraps it in a function so that additional arguments can be passed, which is what you need for the split or a specific root path:

```lua
vim.keymap.set(
    "n",
    "<leader>e",
    function() fyler.open({ kind = "split_left_most" }) end,
    { desc = "Fyler.nvim - Open" }
)
```

The kind option is the one to understand first, because it decides where the file manager appears, and a file manager that opens as a full screen buffer rather than a side split changes the whole feel of the plugin.

## A headless test harness with selectable runs

The Makefile is where the engineering discipline shows, and it is a short file with four real targets in the default build.

Formatting is stylua over the Lua files, linting is selene with the repository's own configuration over the lua and tests directories, the tests run in headless Neovim through a script in bin/, and the docs are generated.

The default target chains format, lint, tests and docs, so a plain make run is the full check. The test runner is invoked as nvim --headless --noplugin -l bin/run_tests.lua, and the tests create a tmp directory and a tests_state file first.

Two of the test targets are unusual and useful. tests_selected lists the available tests, pipes them through fzf with --multi so you can pick a subset, writes the selection into tmp/tests_state, and reruns with the FYLER_NVIM_TEST_SELECTED environment variable set. tests_recent then reruns whatever was last selected, or the full suite if no state file exists, and it fails with a clear message if the state file is missing and tells you to run the other target first.

For a plugin that rewrites file systems, that matters. The interactive selection is the kind of thing that makes it practical to run the suite while you work on the code, and the fact that the test state is persisted in a file rather than in memory means a failure can be reproduced with the same filter.

## Documentation generated from the plugin itself

The docs target is part of the same Makefile and deserves a note, because generating documentation from a plugin is where drift usually starts.

Three generators are wired up, gen_vimdoc, gen_readme and gen_wiki, and each one runs a script from the bin directory with the same headless invocation used by the tests. The docs target depends on all three, so the help file, the README and the wiki pages are all regenerated from the same source in one command.

The repository layout supports that split. The doc/ directory holds the generated help, bin/ holds the generator scripts, lua/ holds the plugin code, plugin/ and ftplugin/ hold the Neovim entry points and filetype behaviour, syntax/ holds the syntax definitions, selene/ holds the lint configuration, and tests/ holds the suite. There is a .stylua.toml for formatting and a .luarc.json for the Lua language server.

The wiki mentioned in the README is a separate thing from the generated wiki pages, and the README asks readers to run :help fyler.nvim or visit the wiki pages for more detailed explanation and a live gallery.

## Where fyler.nvim is the wrong tool

Three cases point elsewhere.

The first is a graphical file manager. This is a Neovim plugin, and if the thing you want is a window outside the editor, with icons and a sidebar, then a native file manager or a file tree plugin with a tree sidebar is a better fit. The credits list includes Neo-tree, which is that kind of plugin, so the distinction is drawn inside the project itself.

The second is a filesystem the plugin cannot reach. The buffer model assumes the plugin can rename and delete paths directly. A remote mount, a network share or a container volume is a different story, and the README does not describe any handling of remote paths, so a project whose files live on a network filesystem needs that answered before adoption.

The third is a team that does not want a plugin rewriting their files silently. That is the premise of the design and it is a good one for a solo developer, but in a shared repository the rename and delete operations need to be reviewable, and the README does not describe an undo, a confirmation or a dry run mode. The cost of a wrong buffer edit here is a wrong file, and the mitigation is a workflow decision that the user has to make.

One last practical note. The newest release is v2.0.0 from 2025-11-23, with an alpha tagged shortly before it, so the 2.x line is recent and still settling. The last push to the repository was on 2026-09-23, so work is continuing after that release, and anyone pinning to the tag should expect the plugin to move.

## Conclusion

Adopt fyler.nvim if you want file operations to feel like buffer editing, if you are on Neovim 0.11 or later, and if you prefer a plugin with a headless test suite and generated documentation over a larger file tree plugin. Do not adopt it if you need a graphical file manager, a remote filesystem client or a file tree that matches a specific plugin's conventions. Verify three things first: your Neovim version, since 0.11 is the stated requirement; whether the buffer-like editing model matches how you work, since that is the whole premise of the plugin and the docs page and wiki are where to check it; and how the plugin behaves on rename and delete, because a file manager that rewrites paths in a buffer needs careful review before you trust it with a large tree. The licence is Apache-2.0, the last push was on 2026-09-23, and the newest release is v2.0.0 dated 2025-11-23.

## FAQ

### What is fyler.nvim?

It is a Neovim file manager plugin, inspired by oil.nvim, which can manipulate the file system like a Neovim buffer while presenting a proper file tree representation of the items. It requires Neovim 0.11 or later.

### How do I install fyler.nvim?

With lazy.nvim, add { 'FylerOrg/fyler.nvim', opts = {} }; with mini.deps, call require('mini.deps').add('FylerOrg/fyler.nvim'); and with vim.pack, call vim.pack.add({ 'https://github.com/FylerOrg/fyler.nvim' }).

### How do I open fyler.nvim and pass options?

Use the :Fyler command, with optional root_path=<path> or kind=<buffer_kind> arguments, or call the Lua API: fyler.open(), fyler.open({ kind = "split_left_most" }) or fyler.open({ root_path = "~" }).

### How are the fyler.nvim tests run?

Through the Makefile, which formats with stylua, lints with selene, runs the suite in headless Neovim with bin/run_tests.lua, and generates the vimdoc, README and wiki. There are also targets to select a subset of tests interactively with fzf and to rerun the last selection.

### Where can I read more about fyler.nvim?

The README points to the built in help with :help fyler.nvim and to the wiki pages for more detailed explanation and a live gallery. The documentation is generated from the plugin itself through the gen_vimdoc, gen_readme and gen_wiki targets.

## Sources

- [FylerOrg/fyler.nvim on GitHub](https://github.com/FylerOrg/fyler.nvim)
- [Issues](https://github.com/FylerOrg/fyler.nvim/issues)
- [License: Apache-2.0](https://github.com/FylerOrg/fyler.nvim/blob/main/LICENSE)
- [README](https://github.com/FylerOrg/fyler.nvim/blob/main/README.md)
- [Releases](https://github.com/FylerOrg/fyler.nvim/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fylerorg-fyler-nvim