# lla replaces ls with views, filters and a plugin platform, at the cost of a Rust workspace with five crates

> A Rust command line file lister that adds tree views, Git awareness, content search, machine readable output and native or WebAssembly plugins to the job ls does. The feature list is unusually wide for a directory listing tool, and the plugin surface is where the maintenance cost sits.

**chaqchase/lla** — blazing fast `ls` replacement with superpowers

- Repository: https://github.com/chaqchase/lla
- Stars: 1,232 · Forks: 26
- Language: Rust
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/chaqchase-lla

## The workspace is five crates, not one binary

lla is a Rust workspace, and the layout in `Cargo.toml` explains a good deal about how the project is built. The members are `lla`, the main crate, plus `interface`, `macros`, `sdk` and `utils`, with `plugins/*` globbed in so every bundled plugin is a workspace member.

The `interface` crate is the plugin contract and is published as `lla_plugin_interface` at the same version as the workspace, and `sdk` is `lla_plugin_sdk`. Plugins therefore load against a versioned ABI, which is the right way to do it: a plugin compiled against one interface version cannot be silently loaded by a binary built for another.

The dependency list is a decent map of what the tool does. `walkdir` and `rayon` handle traversal and parallelism, `libloading` is how native plugins are loaded, `dialoguer` and `indicatif` drive the interactive prompts and progress bars, `regex` and `glob` back the filtering, `atty` and `terminal_size` detect a terminal and its size, `unicode-width` handles wide characters in columns, `strip-ansi-escapes` and `colored` deal with the colour output, and `serde` with `serde_json` and `toml` cover the machine output and the configuration file.

The `prost` and `prost-build` entries, plus `ureq` with json and gzip features, point to a protobuf message format and an HTTP client, which is how plugins are distributed and how the plugin catalogue is reached. The release profile sets `lto = true`, `codegen-units = 1` and `strip = true`, which is the standard set of choices for a binary meant to be installed system wide.

## Six ways to see the same directory

The example commands in the README are the quickest way to understand the scope.

```bash
lla                     # default view
lla -l                  # long view with metadata
lla -t -d 3             # tree view, three levels deep
lla -G                   # Git-aware view
lla --timeline          # group entries by time
lla --search "TODO"     # search file contents
lla --json --pretty     # machine-readable output
```

The default view is compact, the long view adds permissions and metadata, the tree view takes a depth argument, and the Git-aware view surfaces repository status. The timeline groups entries by age, and sizemap compares storage usage, with archives browsable as virtual directories without being extracted first.

The metadata available in the long and table views is where the difference from `ls` becomes concrete: permissions, ownership, timestamps, inode and hard-link counts, allocated size, extended attributes, security context, mount information, symlink targets, and fields contributed by plugins. Permissions can be rendered symbolically, octal, binary, compact or verbose, dates as absolute or relative, and you choose icons, colour, hyperlinks and an explicit column order.

The interactive fuzzy view is the other end of the range. It supports searching, multi-selection, opening files, copying paths, editing and renaming from the terminal. That is a workflow tool, not a listing tool. A fuzzy picker with rename and edit is closer to a file manager than to `ls`.

## Filters combine, and content search runs on ripgrep

Filtering is the part of the design that most affects whether the tool is usable in a script. Entries can be selected by name, extension, glob, regular expression, file type, size, creation time, modification time, dotfile visibility, or Git ignore rules. Compatible name filters combine with AND, OR and NOT expressions, common combinations can be saved as presets, and refinements can be applied sequentially.

That expression language is a real feature, and it is also a real risk. A filter with several predicates combined in the wrong precedence can quietly exclude what you meant to include, and an `ls` replacement is often used in a hurry. The README points at a dedicated filtering and search document for the exact listing and content search compatibility rules, which is the right place to check a predicate before trusting it in a script.

Content search is backed by ripgrep, with literal or regular expression matching, syntax highlighted context and optional plugin action pipelines. Machine output for search has its own documented contract, separate from the listing output, and the README is explicit that the two differ. If you automate against lla, that distinction is the one to read first, because a script that assumes search results share the listing schema will break.

A separate note on scale. The tree and recursive views are described as having configurable depth and safety limits for large directory trees, which tells you the author has hit the case where an unbounded recursive listing is unusable.

## Plugins run in process, or in a WebAssembly sandbox with declared grants

The plugin platform is the most ambitious part of the project and the part with the most room for trouble. Plugins can be installed as official prebuilt packages, built from a local directory, or installed from a Git repository, and the documentation asks you to inspect packages and permissions before running them.

There are two kinds. Native plugins are trusted in-process extensions, loaded through `libloading`, which means they run with the full privileges of the lla process. On builds with the optional `wasm-plugins` feature, WebAssembly Component Model plugins run instead with declared, persisted grants and scoped host capabilities, so the runtime can tell what a plugin has asked for and what it has been given.

The distribution picture is uneven in a way that matters operationally. The official Linux, macOS and Windows release binaries enable the WebAssembly feature. The NetBSD binary, `lla-netbsd-amd64`, supports native plugins but omits the embedded WASM runtime, and the install script selects it on NetBSD amd64. The Windows builds ship native AMD64 and ARM64 executables with matching prebuilt plugin archives, and both include native and WASM plugin support. The PowerShell installer verifies the release checksum and installs `lla.exe` under `%LOCALAPPDATA%\Programs\lla`, and 32-bit x86 Windows is not supported.

The bundled catalog covers metadata, Git context, code analysis, storage insights and file operations, and plugins can add typed listing fields, formatting and actions with human, JSON, NDJSON or CSV output. Typed fields in JSON and NDJSON are what make plugins composable with scripts rather than a gimmick, and that is where lla is more ambitious than the `ls` replacements it resembles.

## Configuration is TOML, with a per repository override

Persistent settings live in `~/.config/lla/config.toml`, and repository specific overrides go in a `.lla.toml` file. The same TOML format is used for command shortcuts, which turn frequently used plugin actions into short top level `lla` commands and can be exported or imported as TOML.

The two level layout is the sensible choice. Global defaults in the home directory apply everywhere, and a repository can override them for that project, which is how a team can ship a shared `.lla.toml` in version control so that everyone on the project gets the same view. The `Cargo.toml` shows `toml` as the parsing dependency, and the `completions/` directory at the repository root, together with the documented generation of completion scripts for Bash, Zsh, Fish, PowerShell and Elvish, means shell integration is a first class concern rather than an afterthought.

The navigation feature deserves a note. A directory jumper combines bookmarks with deduplicated visit history and generates a `j` shell function for Bash, Zsh and Fish, so jumping to a directory is a short command rather than a path. It requires the generated function to be loaded in your shell, which is a small setup step that some people will love and some will never discover.

File and directory diffing is also supported, comparing local paths with each other and against Git references, with unified text diffs plus size or line deltas. That is a `diff` feature inside a listing tool, and it works because the Git awareness is already there.

## Installing means running a script from a URL

The primary install path pipes a script from the repository into a shell.

```bash
curl -sSL https://raw.githubusercontent.com/chaqchase/lla/main/install.sh | bash
```

On Windows PowerShell the equivalent fetches and executes a PowerShell script.

```powershell
irm https://raw.githubusercontent.com/chaqchase/lla/main/install.ps1 | iex
```

Package managers are offered as alternatives, with `cargo install lla` for anyone who already builds Rust projects, `brew install lla` on macOS, `paru -S lla` on Arch Linux, `pkgin install lla` on NetBSD and `x install lla` for X-CMD users. The repository also ships `default.nix`, `flake.nix` and `shell.nix`, so Nix users have a path as well.

After installation, `lla init` creates the configuration, and the getting started guide covers manual downloads, musl limitations, upgrades and initialization options.

The curl-pipe-bash form deserves the usual caution, and here the caveat is sharper than usual because the script is fetched from the `main` branch rather than from a release tag. The content of `main` can change at any time, so the command that installs version 0.6.6 today may install something else tomorrow. Anyone with a policy against piping remote scripts into a shell should use `cargo install lla` or the Homebrew formula instead, and the NetBSD note about the install script selecting the right binary shows the script is doing more than copying a file.

## Release cadence, the MIT licence and the cost of the plugin platform

The last push to the repository was on 2026-10-12 and the recent releases are close together: v0.6.6 on 2026-10-08, v0.6.5 on 2026-09-21 and v0.6.4 on 2026-08-21. The version sits below 1.0, which is a signal that the command line surface may still change between minor versions. A team writing scripts against `lla` should expect to re-check flags when upgrading, and the changelog is at the repository root for that purpose.

The licence is MIT, which is permissive and appropriate for a tool people are expected to install and, in the plugin case, extend. A plugin you write is yours, and a plugin that links the published `lla_plugin_interface` and `lla_plugin_sdk` crates is distributed under terms you choose, since the interface is a separate published crate.

The maintenance cost sits in the plugin platform, not in the listing code. Supporting both native in-process plugins and WebAssembly Component Model plugins means maintaining two extension runtimes, and the per platform differences, with the NetBSD build lacking the WASM runtime, mean the plugin set available to a user is not identical everywhere. The `sdk/` and `interface/` directories in the repository are where that contract lives, and the `plugins/` directory holds the bundled catalog, which means plugin development is a supported activity rather than an accident.

The verdict on maintenance is that the core tool is small and stable, while the ecosystem around it is young and moving. That is an acceptable trade for a personal utility, and a heavier commitment for a tool someone else will depend on.

## Conclusion

Adopt lla if you spend your day in large directories and want one tool for listing, tree navigation, content search and scriptable output, and you are comfortable installing a binary and a config file in your home directory. Do not adopt it if your environment blocks unvetted install scripts, or if you need the same tool to behave identically on every machine, because plugin support differs per release binary: the official Linux, macOS and Windows builds enable WebAssembly plugins while the NetBSD build does not. Verify first that `lla init` writes a config you can read, that the JSON output schema matches what your scripts expect, and that any plugin you install is one you have looked at, since plugins execute in process with the permissions you grant them.

## FAQ

### How do I install lla and set it up?

Run lla init after installation to create the configuration. The README offers curl -sSL https://raw.githubusercontent.com/chaqchase/lla/main/install.sh | bash, the PowerShell equivalent, and package managers including cargo install lla, brew install lla, paru -S lla, pkgin install lla and x install lla.

### Does lla support plugins, and which kind?

Yes. Native plugins are trusted in-process extensions, and on release builds with the wasm-plugins feature, WebAssembly Component Model plugins run with declared, persisted grants and scoped host capabilities. Official Linux, macOS and Windows binaries enable the feature, while the NetBSD binary omits the embedded WASM runtime.

### Where does lla keep its configuration?

Global defaults live in ~/.config/lla/config.toml, and repository specific overrides go in a .lla.toml file in the project. Command shortcuts can also be exported or imported as TOML.

### Can lla produce output for scripts?

Yes. It can emit a JSON array, newline-delimited JSON or fixed-schema CSV while keeping the selected path, sort, filter, depth and archive behavior, and JSON and NDJSON include typed plugin fields. Content search has its own separate machine output contract.

### Which platforms does lla support?

The README documents Windows with native AMD64 and ARM64 executables, with 32-bit x86 Windows unsupported, and Windows 10 or Windows Server 2016 and newer required. A NetBSD amd64 release named lla-netbsd-amd64 is published, and the getting started guide notes musl limitations.

## Sources

- [chaqchase/lla on GitHub](https://github.com/chaqchase/lla)
- [Issues](https://github.com/chaqchase/lla/issues)
- [License: MIT](https://github.com/chaqchase/lla/blob/main/LICENSE)
- [README](https://github.com/chaqchase/lla/blob/main/README.md)
- [Releases](https://github.com/chaqchase/lla/releases)

---

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