Convert Figma logo to code with AI

JohnnyMorganz logoStyLua

An opinionated Lua code formatter

1,524
68
1,524
59

Top Related Projects

5,953

Format Rust code

49,046

Prettier is an opinionated code formatter.

A tool for linting and static analysis of Lua code.

Quick Overview

StyLua is a tool that automatically formats Lua code to adhere to a consistent style guide. It is designed to be used as a pre-commit hook or as part of a continuous integration pipeline, ensuring that all code in a project follows the same formatting conventions.

Pros

  • Consistent Code Formatting: StyLua ensures that all Lua code in a project follows the same formatting conventions, making the codebase more readable and maintainable.
  • Customizable Style Guide: StyLua allows users to customize the formatting rules to fit their specific preferences or project requirements.
  • Integrates with Git: StyLua can be easily integrated into a Git-based workflow, allowing developers to automatically format their code before committing it.
  • Supports Multiple Lua Versions: StyLua supports a wide range of Lua versions, from Lua 5.1 to Lua 5.4 and LuaJIT.

Cons

  • Opinionated Style Guide: While the default style guide provided by StyLua is well-designed, some developers may prefer a different set of formatting rules.
  • Potential Conflicts with Other Formatting Tools: If a project already uses a different Lua formatting tool, integrating StyLua may require additional configuration or migration efforts.
  • Potential Performance Impact: Depending on the size of the codebase, running StyLua on every commit or in a continuous integration pipeline may have a noticeable performance impact.
  • Limited Scope: StyLua is focused solely on code formatting and does not provide other code analysis or linting features that some developers may find useful.

Code Examples

StyLua is a command-line tool, so there are no code examples to provide. However, here's an example of how you might use StyLua in a Git pre-commit hook:

#!/bin/bash

# Run StyLua on all Lua files in the repository
stylua --check --color always .

This script would run StyLua on all Lua files in the repository and fail the pre-commit hook if any files need to be formatted.

Getting Started

To get started with StyLua, follow these steps:

  1. Install StyLua using your preferred method (e.g., luarocks install stylua or downloading the binary from the GitHub releases page).

  2. Create a configuration file (.stylua.toml) in the root of your Lua project, specifying your desired formatting rules. Here's an example configuration:

    line_width = 120
    indent_width = 2
    quote_style = "AutoPreferSingle"
    
  3. Integrate StyLua into your development workflow, such as by adding a pre-commit hook or running it as part of your continuous integration pipeline.

    For example, to use StyLua as a pre-commit hook, you can add the following script to your project's .git/hooks/pre-commit file:

    #!/bin/bash
    
    # Run StyLua on all Lua files in the repository
    stylua --check --color always .
    

    This script will run StyLua on all Lua files in the repository and fail the pre-commit hook if any files need to be formatted.

  4. (Optional) Customize the StyLua configuration to match your project's specific formatting preferences by modifying the .stylua.toml file.

That's it! With StyLua integrated into your development workflow, your Lua codebase will maintain a consistent style across all contributors.

Competitor Comparisons

5,953

Format Rust code

Pros of rustfmt

  • Official Rust formatter, ensuring consistency with Rust's style guidelines
  • Integrated with Rust toolchain, making it easy to use and update
  • Supports a wide range of Rust-specific syntax and features

Cons of rustfmt

  • Limited customization options compared to StyLua
  • Slower performance on large codebases
  • Less flexible in handling edge cases or unique formatting preferences

Code Comparison

rustfmt:

fn main() {
    let x = vec![1, 2, 3];
    println!("Hello, world!");
}

StyLua:

local function main()
    local x = { 1, 2, 3 }
    print("Hello, world!")
end

While both formatters aim to improve code readability, rustfmt focuses on Rust-specific syntax and conventions, while StyLua is tailored for Lua's unique language features. rustfmt benefits from being the official Rust formatter, ensuring widespread adoption and consistency across the Rust ecosystem. However, StyLua offers more customization options and potentially better performance for large Lua codebases. The code comparison demonstrates the different syntax between Rust and Lua, highlighting the need for language-specific formatters.

49,046

Prettier is an opinionated code formatter.

Pros of Prettier

  • Supports multiple languages (JavaScript, TypeScript, CSS, HTML, JSON, and more)
  • Highly configurable with extensive options
  • Large community and ecosystem with numerous plugins and integrations

Cons of Prettier

  • Can be opinionated, sometimes forcing unwanted formatting choices
  • May have performance issues with very large files or projects
  • Learning curve for advanced configuration and customization

Code Comparison

StyLua:

local function example(a, b)
    return a + b
end

Prettier (JavaScript):

function example(a, b) {
  return a + b;
}

Key Differences

  • StyLua is specifically designed for Lua, while Prettier supports multiple languages
  • Prettier has a larger community and more extensive features, but StyLua is more focused on Lua-specific formatting
  • StyLua may offer more fine-grained control over Lua formatting, while Prettier provides a more standardized approach across languages

Use Cases

  • Choose StyLua for Lua-specific projects requiring tailored formatting
  • Opt for Prettier in multi-language projects or when working with popular web technologies

Community and Support

  • Prettier has a larger user base and more frequent updates
  • StyLua, being more specialized, may have a smaller but dedicated community focused on Lua development

A tool for linting and static analysis of Lua code.

Pros of luacheck

  • More comprehensive static analysis and linting capabilities
  • Detects a wider range of potential issues and code smells
  • Highly configurable with many options for customization

Cons of luacheck

  • Primarily focused on linting and doesn't offer code formatting
  • May produce more false positives due to its strict analysis
  • Slower performance on large codebases compared to StyLua

Code Comparison

StyLua (formatting):

local function example(a,b,c)
    print(a,b,c)
end

luacheck (linting output):

example.lua:1:21: unused argument 'c'
example.lua:2:11: multiple statements on a line

StyLua focuses on formatting and would adjust the code's style, while luacheck identifies potential issues like unused variables and multiple statements on a single line.

Both tools serve different purposes in the Lua ecosystem. StyLua is primarily a code formatter, ensuring consistent style across projects. luacheck, on the other hand, is a static analyzer and linter, helping developers identify potential bugs and improve code quality. While they have some overlapping functionality, they are often used in conjunction to achieve both well-formatted and high-quality Lua code.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

StyLua

An opinionated code formatter for Lua 5.1, 5.2, 5.3, 5.4 and Luau, built using full-moon. StyLua is inspired by the likes of prettier, it parses your Lua codebase, and prints it back out from scratch, enforcing a consistent code style.

StyLua mainly follows the Roblox Lua Style Guide, with a few deviations.

Installation

There are multiple ways to install StyLua:

With Github Releases

Pre-built binaries are available on the GitHub Releases Page.

By default, these are built with all syntax variants enabled (Lua 5.2, 5.3, 5.4 and Luau), to cover all possible codebases. If you would like to format a specific Lua version only, see installing from crates.io.

From Crates.io

If you have Rust installed, you can install StyLua using cargo. By default, this builds for just Lua 5.1. You can pass the --features <flag> argument to build for Lua 5.2 (lua52), Lua 5.3 (lua53), Lua 5.4 (lua54) or Luau (luau)

cargo install stylua
cargo install stylua --features lua52
cargo install stylua --features lua53
cargo install stylua --features lua54
cargo install stylua --features luau

GitHub Actions

You can use the stylua-action GitHub Action in your CI to install and run StyLua. This action uses the prebuilt GitHub release binaries, instead of running cargo install, for faster CI times.

pre-commit

You can use StyLua with pre-commit. There are 3 possible pre-commit hooks available:

  • stylua: installs via cargo - requires the Rust toolchain
  • stylua-system: runs a stylua binary available on the PATH. The binary must be pre-installed
  • stylua-github: automatically installs the relevant prebuilt binary from GitHub Actions

Add the following to your .pre-commit-config.yaml file:

- repo: https://github.com/JohnnyMorganz/StyLua
  rev: v0.20.0
  hooks:
    - id: stylua # or stylua-system / stylua-github

npm

StyLua is available as a binary published to npm as @johnnymorganz/stylua-bin. This is a thin wrapper which installs the binary and allows it to be run through npm.

npx @johnnymorganz/stylua-bin --help

StyLua is also available as a WASM library at @johnnymorganz/stylua. It is usable in Node.js, or in the browser (using a bundler).

Docker

StyLua is available on the Docker Hub.

If you are using Docker, the easiest way to install StyLua is:

COPY --from=JohnnyMorganz/StyLua:0.20.0 /stylua /usr/bin/stylua

Homebrew

StyLua is available on macOS via the Homebrew package manager.

brew install stylua

Other Installation Methods

aftman add johnnymorganz/stylua@0.14.2
  • A community maintained package repository. Please note, these packages are maintained by third-parties and we do not control their packaging manifests.

Community Packages

Other Editor Integrations

Note that these integrations require the StyLua binary to already be installed and available on your system.

Usage

Once installed, pass the files to format to the CLI:

stylua src/ foo.lua bar.lua

This command will format the foo.lua and bar.lua file, and search down the src directory to format any files within it. StyLua can also read from stdin, by using - as the file name.

Glob Filtering

By default, when searching through a directory, StyLua looks for all files matching the glob **/*.lua (or **/*.luau when luau is enabled) to format. You can also specify an explicit glob pattern to match against when searching:

stylua --glob '**/*.luau' -- src # format all files in src matching **/*.luau
stylua -g '*.lua' -g '!*.spec.lua' -- . # format all Lua files except test files ending with `.spec.lua`

Note, if you are using the glob argument, it can take in multiple strings, so -- is required to break between the glob pattern and the files to format.

By default, glob filtering (and .styluaignore files) are only applied for directory traversal and searching. Files passed directly (e.g. stylua foo.txt) will override the glob / ignore and always be formatted. To disable this behaviour, pass the --respect-ignores flag (stylua --respect-ignores foo.txt).

Filtering using .styluaignore

You can create a .styluaignore file, with a format similar to .gitignore. Any files matching the globs in the ignore file will be ignored by StyLua. For example, for a .styluaignore file with the following contents:

vendor/

running stylua . will ignore the vendor/ directory.

--check: Checking files for formatting

To check whether files have been formatted (but not write directly to them), use the --check flag. It will take files as input, and output a diff to stdout instead of rewriting the file contents. If there are files which haven't been fully formatted, StyLua will exit with status code 1.

By default, we provide a custom Standard diff view, but this can be configured:

  • --output-format=unified: output a unified diff, which can be consumed by tools like patch or delta
  • --output-format=json: output JSON representing the changes, useful for machine-readable output

--verify: Verifying formatting output

As a safety measure, the --verify flag can be passed to StyLua, and StyLua will verify the output of all formatting before saving it to a file.

If enabled, the tool will re-parse the formatted output to verify if the AST is still valid (no syntax errors) and is similar to the input (possible semantic changes).

Useful when adopting StyLua in a large codebase, where it is difficult to verify all formatting is correct. Note that this may produce false positives and negatives - we recommend manual verification as well as running tests to confirm.

Ignoring parts of a file

To skip formatting a particular part of a file, you can add -- stylua: ignore before it. This may be useful if there is a particular style you want to preseve for readability, e.g.:

-- stylua: ignore
local matrix = {
    { 0, 0, 0 },
    { 0, 0, 0 },
    { 0, 0, 0 },
}

Formatting can also be skipped over a block of code using -- stylua: ignore start and -- stylua: ignore end:

local foo = true
-- stylua: ignore start
local   bar   =   false
local  baz      = 0
-- stylua: ignore end
local foobar = false

Note that ignoring cannot cross scope boundaries - once a block is exited, formatting will be re-enabled.

Formatting Ranges

To format a specific range within a file, use --range-start <num> and/or --range-end <num>. Both arguments are inclusive and optional - if an argument is not provided, the start/end of the file will be used respectively.

Only whole statements lying within the range will be formatted. If part of a statement falls outside the range, the statement will be ignored.

In editors, Format Selection is supported.

Requires Sorting

StyLua has built-in support for sorting require statements. We group consecutive require statements into a single "block", and then requires are sorted only within that block. Blocks of requires do not move around the file.

We only include requires of the form local NAME = require(EXPR), and sort lexicographically based on NAME. (We also sort Roblox services of the form local NAME = game:GetService(EXPR))

Requires sorting is off by default. To enable it, add the following to your stylua.toml:

[sort_requires]
enabled = true

Configuration

StyLua is opinionated, so only a few options are provided.

Finding the configuration

The CLI looks for stylua.toml or .stylua.toml in the directory where the tool was executed. If not found, we search for an .editorconfig file, otherwise fall back to the default configuration. This feature can be disabled using --no-editorconfig. See EditorConfig for more details.

A custom path can be provided using --config-path <path>. If the path provided is not found/malformed, StyLua will exit with an error.

By default, the tool does not search further than the current directory. Recursively searching parent directories can be enabled using --search-parent-directories. This will keep searching ancestors. If not found, it will then look in $XDG_CONFIG_HOME / $XDG_CONFIG_HOME/stylua.

Note: enabling searching outside of the current directory is NOT recommended due to possibilities of conflicting formatting:

It is recommended to keep a .stylua.toml file in your project root so that other developers can make use of the same configuration.

If a project uses the default configuration of StyLua without a configuration file present, enabling external searching may cause conflicting formatting.

Options

StyLua only offers the following options:

OptionDefaultDescription
column_width120Approximate line length for printing. Used as a guide for line wrapping - this is not a hard requirement: lines may fall under or over the limit.
line_endingsUnixLine endings type. Possible options: Unix (LF) or Windows (CRLF)
indent_typeTabsIndent type. Possible options: Tabs or Spaces
indent_width4Character size of single indentation. If indent_type is set to Tabs, this option is used as a heuristic to determine column width only.
quote_styleAutoPreferDoubleQuote style for string literals. Possible options: AutoPreferDouble, AutoPreferSingle, ForceDouble, ForceSingle. AutoPrefer styles will prefer the specified quote style, but fall back to the alternative if it has fewer string escapes. Force styles always use the specified style regardless of escapes.
call_parenthesesAlwaysWhether parentheses should be applied on function calls with a single string/table argument. Possible options: Always, NoSingleString, NoSingleTable, None, Input. Always applies parentheses in all cases. NoSingleString omits parentheses on calls with a single string argument. Similarly, NoSingleTable omits parentheses on calls with a single table argument. None omits parentheses in both cases. Note: parentheses are still kept in situations where removal can lead to obscurity (e.g. foo "bar".setup -> foo("bar").setup, since the index is on the call result, not the string). Input removes all automation and preserves parentheses only if they were present in input code: consistency is not enforced.
collapse_simple_statementNeverSpecify whether to collapse simple statements. Possible options: Never, FunctionOnly, ConditionalOnly, or Always

Default stylua.toml, note you do not need to explicitly specify each option if you want to use the defaults:

column_width = 120
line_endings = "Unix"
indent_type = "Tabs"
indent_width = 4
quote_style = "AutoPreferDouble"
call_parentheses = "Always"
collapse_simple_statement = "Never"

[sort_requires]
enabled = false