johnnymorganz/stylua

An opinionated Lua code formatter

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

• VSCode Extension
• Aftman

aftman add johnnymorganz/[email protected]

• A community maintained package repository. Please note, these packages are maintained by third-parties and we do not control their packaging manifests.

Other Editor Integrations

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

• Sublime: Sublime Text Package
• Neovim: stylua-nvim / stylua.nvim

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:

Option	Default	Description
column_width	120	Approximate 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_endings	Unix	Line endings type. Possible options: Unix (LF) or Windows (CRLF)
indent_type	Tabs	Indent type. Possible options: Tabs or Spaces
indent_width	4	Character size of single indentation. If indent_type is set to Tabs, this option is used as a heuristic to determine column width only.
quote_style	AutoPreferDouble	Quote 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_parentheses	Always	Whether 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_statement	Never	Specify 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

stylua's Issues

Situations where StyLua should/shouldn't wrap onto new lines

Below is an example where I'm not entirely sure if it should be wrapped or not:

error(
    "Owner `" .. tostring(owner) .. "` already has a pawn. Try deleting their currently owned pawn."
)

This needs to be thought about and then determined on what to do

List indentation shifts to the left on the first & last values

The current behavior of formatting a large list that spans multiple lines will put the top and bottom values of a table on the complete left side of the document.

Test code:

local Suffixes = {"k", "M", "B", "T", "qd", "Qn", "sx", "Sp", "O", "N", "de", "Ud", "DD", "tdD", "qdD", "QnD",
	"sxD", "SpD", "OcD", "NvD", "Vgn", "UVg", "DVg", "TVg", "qtV", "QnV", "SeV", "SPG", "OVG",
	"NVG", "TGN", "UTG", "DTG", "tsTG", "qtTG", "QnTG", "ssTG", "SpTG", "OcTG", "NoTG", "QdDR",
	"uQDR", "dQDR", "tQDR", "qdQDR", "QnQDR", "sxQDR", "SpQDR", "OQDDr", "NQDDr", "qQGNT", "uQGNT",
	"dQGNT", "tQGNT", "qdQGNT", "QnQGNT", "sxQGNT", "SpQGNT", "OQQGNT", "NQQGNT", "SXGNTL"}

Indentation of function block within expanded expression is too low

Function blocks within expanded expressions seem to base their indentation on that of the line on which the expression begins.

local expr = first_______________________________________________________________________________________________________
	and function()
	foo()
end

Both my text editor (VS Code) and I expect the indentation to be based on the line where the function block begins:

local expr = first_______________________________________________________________________________________________________
	and function()
		foo()
	end

I say VS Code expects this because that's the indentation level it gives me when I enter onto a new line, starting from the end of function()

unexpected token `type`

On current main (hash d870087), in a file where I have

type Array<T> = { [number]: T }

I get this error:

error: could not format file definition.lua: error parsing: error occurred while creating ast: unexpected token `type`. (starting from line 30, character 1 and ending on line 31, character 5)
additional information: leftover token

It would be nice if it would skip that AST parent node and proceed, rather than erroring.

Indentation Level of 'then

I'm closing this and reopening with a better title. This issue was unintentionally posted before being completed.

Issue with very long lines of variable declarations

Continued from #48 (comment)

Issue is looks a bit awkward

Allow use of an ignore file

It would be really useful to have a file similar to a .prettierignore (something like .styluaignore possibly) that allows coordination of which files to format without having to pass options to command line every time. This would allow much easier adoption in git projects that are already familiar with this style of collaboration coordination.

Wrap comments when they excede a certain line length

Comments should ideally be wrapped at a certain line length to maintain readability. Roblox's style guide suggests 80, which is what I use, but I've also seen people use 120 or any random number.

This should ideally apply only to comments that on on lines by themselves (blah() --todo foobar shouldn't be formatted) and wrap at word boundaries (which can be accomplished with a basic regex pattern). To avoid styling the comment or ruining LDoc, it should maintain any trivia at the beginning of the comment (e.g. preserve --- and -- ).

Format number literals if they begin with a decimal

For consistency across a codebase, we should format number literals if they begin with a decimal.
i.e. .5 would be formatted to 0.5

Preserve Comments

Comments are treated as trivia and are not preserved in the format

Configuration files need to be complete

I had a stylua.toml with:

line_endings = "Windows"

...and got the following error: config file not in correct format: missing field indent_type at line 1 column 1

Moving code onto one line with comment breaks code

Before running StyLua:

local foo_result = foo( --a comment
	"oof"
)

local expr_result = 1 + 2 + 3 + 4 + 5 --a comment
	+ 6 + 6 + 8

After running StyLua:

local foo_result = foo( --a comment"oof")

local expr_result = 1 + 2 + 3 + 4 + 5 --a comment + 6 + 6 + 8

Formatting removing required semicolons

In code such as the following, it removes the required semicolon, which breaks the code.

function PlayerPromise.PromiseUserIdFromName(Username: string)
	return Promise.Defer(function(Resolve, Reject)
		local Success, Value = pcall(Players.GetUserIdFromNameAsync, Players, Username);
		(Success and Resolve or Reject)(Value)
	end)
end

Break up long if statement conditions

if someReallyLongCondition and someOtherReallyLongCondition and somethingElse then
    doSomething()
    doSomethingElse()
end

... should be formatted as ...

if
    someReallyLongCondition
    and someOtherReallyLongCondition
    and somethingElse
then
    doSomething()
    doSomethingElse()
end

Incorrect type formatting for anonymous functions in Luau

local Object = {ClassName = "Object"}
Object.__tostring = function(self): string
    return self.ClassName
end

... is output as ...

local Object = { ClassName = "Object" }
Object.__tostring = function(self)
: string	return self.ClassName
end

A newline diff at the end of a file doesn't clear the terminal colour

Terminal output isn't cleared when using a newline diff at the end of a file - causing any errors shown at the end to be the incorrect colour.
Note: from what I can tell, the colour does seem to clear once the program has exited

Single Multi-line if Statement

StyLua uses multi-line if statement formatting even when the expression will only be put on a single line:

if
	not (one and two and three and four and five and six and seven and eight and nine and ten and eleven and twelve and thirteen and fourteen and fifteen and sixteen)
then

end

In this case, I might expect it to remain on one line or be broken up (with a higher indentation).

Question about Configuration Options

Hey there! I know you said this is very opinionated but I was wondering which configuration options you are going to/willing to add in the future. I'm very interested in using this as a replacement for LuaFormatter which does allow the following https://github.com/Koihik/LuaFormatter#default-configuration

Attempting to match globs finds no files

Using the example in the readme for avoiding matching .spec.lua files or modified ones like stylua -g **/*.lua -g !**/*.spec.lua . just returns error: no files provided. Ideally this should match against regular .lua files that are discoverable in the path given.

This seems to be related to the glob option matching multiple patterns following it and the path to run on being treated as a glob. stylua -g **/*.lua . has this problem, but stylua -g **/*.lua --check . does not.

Configuration for quote style of strings

Quote style (single quote vs double quote) for strings is a hot topic, including what to do with escapes, consistency etc.
I was wondering whether we should introduce configuration for this specific point.

There would have to be two parts to this:

1. quote style (single quote or double quote), and
2. forcing quote style - should we force the chosen quotes regardless of whether we could reduce the number of escapes in the string or not? There are arguments for this (consistency with all strings in codebase) and against (reduce number of escapes necessary, making string easier to read).

So, there are two questions to answer here: 1) should we add this configuration option? and 2) what should be our default? [currently our default is double quote - which will remain so - and forcing regardless of escapes - which I'm not sure which is better]

VS Code extension doesn't respect .styluaignore

When adding a directory to ignore then formatting a file in that directory it will apply the formatting to it. I would guess due to not checking the directory opened in VS Code to check for a .styluaignore file.

if... then ... else statements not aligned when wrapped and indented

Input

local myObj = {
	myProp = function(reallyLongVariableNameEatsUpSpace)
		if
			reallyLongVariableNameEatsUpSpace == "foo"
			or reallyLongVariableNameEatsUpSpace == "bar"
			or reallyLongVariableNameEatsUpSpace == "baz"
		then
			return "hello"
		end
	end,
}

Output

local myObj = {
	myProp = function(reallyLongVariableNameEatsUpSpace)
		if
			reallyLongVariableNameEatsUpSpace == "foo"
			or reallyLongVariableNameEatsUpSpace == "bar"
			or reallyLongVariableNameEatsUpSpace == "baz"
	then
			return "hello"
		end
	end,
}

Expected Behavior

The then statement should be aligned with the corresponding if ... end blocks

- 	then
+ 		then

PS: This project is amazing and solving so many issues - hope my edge case detection / bug reporting is helpful, but very grateful to have 95%+ of our formatting auto solved.

Use column width as a bigger indicator when to split lines

Currently, the formatted chooses to split lines by determining the number of bytes between the contained span braces (for TableConstructor and FunctionArgs).
This isn't great, as it doesn't take into account the current column width (e.g. if we are a few indents deep)

Column width should be used as the deciding factor about when to introduce line breaks (need to find a way to calculate this as the formatters currently "don't know about their surroundings")

Double quotes preceded by escaped backslash

Input:

local str = '\\"""'

Output:

local str = "\\"\"\""

Expected:

local str = "\\\"\"\""

Preserve the escape on the \ character and then escape the first double quote since the string has been converted to double quotes. It would be nice if strings were formatted to avoidEscapes, but for simplicity - forcing into double quotes seems fine too.

A multiline comment is not indented correctly for the opening brace

function foo()
    function bar()
        function baz()
            --[[
                comment
            ]]
            local x = 1
        end
    end
end

... is formatted as ...

function foo()
	function bar()
		function baz()
--[[
                            comment
                        ]]
			local x = 1
		end
	end
end

Allow checking that files are already formatted

This would be similar to prettier --check (prettier also uses prettier --write when formatting the files to distinguish) and would allow quick checks that the project is already compliant with the formatting created by StyLua. This can help with CI checks to ensure everyone is using StyLua in their contributions easily.

File globs overridden in .styluaignore by command line globs argument

When adding something such as *.spec.lua to .styluaignore then running stylua --check . a diff is produced for *.spec.lua files.

Possibly related to #20.

Comments wrap incorrectly at the beginning of tables

return { -- comment
    hello = "world",
    foo = "bar",
}

... is formatted as ...

return {
 -- comment    hello = "world",
    foo = "bar",
}

Table types in Luau do not correctly move onto new lines

type PromptSettings = {
    object: string,
    action: string,
    holdDuration: number,
    keyboardKey: KeyCode,
    gamepadKey: KeyCode,
    distance: number,
    lineOfSight: boolean,
    offset: Vector2,
}

... should be kept the same, but it is reformatted as ...

type PromptSettings = { object: string, action: string, holdDuration: number, keyboardKey: KeyCode, gamepadKey: KeyCode, distance: number, lineOfSight: boolean, offset: Vector2,  }

Remove excess parentheses

Stylua should remove excess parentheses where it is safe to do so.

local x
something((x))

should become:

local x
something(x)

However, it's not always safe to remove parentheses. Inside of binary operator expressions, parentheses can denote precedence, so these parentheses should not be removed:

local x = (1 + 2) * 3

Additionally, parentheses can cull extra values returned from a multiple return:

function x()
  return 1, 2
end

print(x()) --> 1, 2
print((x())) --> 1

In this example above, removing the parentheses in the expression (x()) is unsafe, because it changes how the code runs.

In cases like this, Stylua should still compress down to one set: print(((x()))) should become print((x())).

Code getting commented out on new lines

Code can get commented out and ruin the file.

Original:

-- Stop Movement
if
	-- Moved for at least 0.1 seconds
	((tick() - Player.PlayerDataLocal.IsRunningTimeStamp.Value) > 0.1) and     -- Speed is less than threshold
	(Utility.Vec3XZLengthSquared(Player.Character.PrimaryPart.Velocity) <= RunThresholdSpeedSqr)
then --0.01
	Player.PlayerDataLocal.IsRunning.Value = false
end

Formatted:

-- Stop Movement
if
-- Moved for at least 0.1 seconds
	((tick() - Player.PlayerDataLocal.IsRunningTimeStamp.Value) > 0.1)
	and  -- Speed is less than threshold(Utility.Vec3XZLengthSquared(Player.Character.PrimaryPart.Velocity) <= RunThresholdSpeedSqr)
then --0.01
	Player.PlayerDataLocal.IsRunning.Value = false
end

Comments at the end of line continuations

Input:

if code == 9 -- \t
or code == 32 -- <space>
   then
    print(code)
end

Output:

if code == 9 -- \t or code == 32 -- <space> then
	print(code)
end

Expected (combine code and comments serially):

if code == 9 or code == 32 then -- \t  -- <space> 
	print(code)
end

Expected (do nothing if removing new line will place executing code inside a comment):

if code == 9 -- \t
or code == 32 -- <space>
   then
    print(code)
end

^{(same as input)}

or do nothing if removing a newline is going to

Indentation level of multiline-if 'then' does not respect the expanded function calls it is nested within

The indentation level of 'then' in multi-line if statements appears to decrease by one for every expanded function call it's nested in.

baz(
	first_arg___ooooooooooooooooooooooooooooooooooooooooooo,
	second_arg___qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq,

	function()
		if
			multiline_if___aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
			and multiline_if___bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
	then
			biz()
		end
	end
)

biz(
	first_arg___aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
	second_arg___bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,

	baz(
		first_arg___ooooooooooooooooooooooooooooooooooooooooooo,
		second_arg___qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq,

		function()
			if
				multiline_if___aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
				and multiline_if___bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
	then
				biz()
			end
		end
	)
)

This exact problem does not appear to exist for expanded expressions that aren't function calls:

local result = first_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
	and (function()
	if
		multiline_if___aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
		and multiline_if___bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
	then

	end

	return second
end)()

Trailing comments of a semicolon are lost

bug or feature? :)

Repeat until loops aligns the until line to the left

Currently, repeat ... until ... loops are left aligned to the entire document, which should not happen & should align with the repeat line.

Test code:

local function Foo(bar)
	local count = 0

	repeat
		count += 1
	until count == 10
end

Foo('thing')

Format this and the following is generated:

local function Foo(bar)
	local count = 0

	repeat
		count += 1
until count == 10
end

Foo("thing")

Eager Wrapping with Comments

This input gets wrapped eagerly.

last = last or #array -- If last isn't provided, go to the end

Becoming this, due to the comment.

last = last
	or #array -- If last isn't provided, go to the end

However, this remains unchanged.

last = last or #array

Comments which are binded to tokens at the end of an indentation block have incorrect indentation

function foo()
    local x = 1
    local y = 1

    -- comment
end

... is formatted as ...

function foo()
    local x = 1
    local y = 1

-- comment
end

(Note: A single line comment at the start of a block formats fine)

Hang expressions within a function call if necessary

There are situations where codebases have strings concatenated together so that they can push them onto multiple lines, to improve the readability.
For example:

local longString = foo(
     "We are wrapping this %s "
    .. "onto multiple lines "
    .. "for ease of editing and %d readability", 
    myStringVar, 
    myNumberVar
)

We should keep them expanded if that is the case (with the similar logic as to what we do with already expanded tables)

Trailing comment forces new line when not necessary

Input

local val = 1 + 1 -- add

Output

local val = 1
	+ 1 -- add

Expected Output

local val = 1 + 1 -- add

Environment

Happens against the latest release and also a local build off master

Luau 'type' keyword isn't supported

Any file I have that includes any mention of the type keyword cannot be formatted.
Small example:

type Array<T> = { [number]: T }
type Set<T> = { [T]: boolean }

I would be fine if this part of the AST was transferred without any attempts at formatting :)

unexpected token `:`

With this code in a file:

function serializeInt(outputValue): number
end

I get this error:

error: could not format file scalars.lua: error parsing: error occurred while creating ast: unexpected token `:`. (starting from line 28, character 35 and ending on line 28, character 36)
additional information: expected 'end'

Maintain `do` block formatting

do blocks get moved down from their original starting line, which should not occur if it causes no issues.

What I wrote:

local thing = {} do
	thing.__index = thing

	function thing.new()
		return setmetatable({ key = "hi" }, thing)
	end

	function thing:method()
		print(self.key)
	end
end

What's formatted:

local thing = {}
do
	thing.__index = thing

	function thing.new()
		return setmetatable({ key = "hi" }, thing)
	end

	function thing:method()
		print(self.key)
	end
end

The do should not move below the line.

Expressions of sufficient length should be split into multiple lines

Left = old, right = new.

VSCode: Format selection command

A Format Selection with Stylua command would make it easier to format small parts of a file. This is useful when you are working on a large file, and only want your new changes to be affected by the formatting.

Could not format file: thread 'main' has overflowed its stack

We have an unusual edge case which returns the error:

Could not format file: thread 'main' has overflowed its stack

The following block of code fails when including the last expression in the if statement

if
	code == 65
	or code == 66
	or code == 67
	or code == 68
	or code == 69
	or code == 70
	or code == 71
	or code == 72
	or code == 73
	or code == 74
	or code == 75
	or code == 76
	or code == 77
	or code == 78
	or code == 79
	or code == 80
	or code == 81
	or code == 82
	or code == 83
	or code == 84
	or code == 85
	or code == 86
	or code == 87
	or code == 88
	or code == 89
	or code == 90
	or code == 95
	or code == 97
	or code == 98
	or code == 99
	or code == 100
	or code == 101
	or code == 102
	or code == 103
	or code == 104
	or code == 105
	or code == 106
	or code == 107
	or code == 108
	or code == 109
	or code == 110
	or code == 111
	or code == 112
	or code == 113
	or code == 114
	or code == 115
				or code == 116
then
	print("hi")

end

It's definitely a strange edge case, and there are ways to rewrite the code to avoid this, but we have some constraints that prevent excessive rewrites.

repeat-until loops should not create an extra new line

repeat
until false

will format into:

repeat
until 
false

Double quotes are escaped again within a string

local x = "foo \"bar\" baz"

... is formatted to ...

local x = "foo \\"bar\\" baz"

and this keeps happening whenever StyLua is run

Preserve trailing comments in multiline tables

Currently, if you have a comment at the end of an entry in a table with a comma:

local foo = {
    foo = bar, -- this is a comment
    bar = baz
}

... it isn't preserved.

In addition, if you have do not have a trailing comma, and have a comment ...

local foo = {
    foo = bar,
    bar = baz -- comment
}

... StyLua incorrectly places the comma ...

local foo = {
    foo = bar,
    bar = baz -- comment,
}

Incorrectly expands function call containing comments

With the recent update, a function call containing comments now becomes expanded, when we do not want it to be

For example:

local App = Roact.createElement("Frame", {
	Size = UDim2.fromScale(0.5, 0), -- comment
	foo = bar,
}, {
	foo = bar
})

should remain the same, however it is incorrectly formatted as

local App = Roact.createElement(
	"Frame",
	{
		Size = UDim2.fromScale(0.5, 0), -- comment
		foo = bar,
	},
	{
		foo = bar,
	}
)

EDIT: This seems to actually be a regression from v0.2.1 -> v0.3.0

Remove empty lines from start & end of block

function foo()

    local x = 1

end

... should be formatted as ...

function foo()
    local x = 1
end