Skip to content

fix: normalize leading whitespaces in multiline go code#1305

Merged
a-h merged 1 commit intoa-h:mainfrom
davidsama:main
Dec 31, 2025
Merged

fix: normalize leading whitespaces in multiline go code#1305
a-h merged 1 commit intoa-h:mainfrom
davidsama:main

Conversation

@davidsama
Copy link
Copy Markdown
Contributor

@davidsama davidsama commented Nov 23, 2025

I had an issue where templ fmt would add an extra newline and leading tabs in the beginning of every multiline go code expression in templates. My case looked like this:

 templ treeViewItem(item TreeViewItem, depth int) {
	<details>
		{{
			rawUrl := ""
			if depth == 1 {
				rawUrl = fmt.Sprintf("/system/%d", item.id)
			} else if depth == 2 {
				rawUrl = fmt.Sprintf("/central/%d", item.id)
			} else if depth == 3 {
				rawUrl = fmt.Sprintf("/department/%d", item.id)
			}
		}}
        ...

which got formatted to:

 templ treeViewItem(item TreeViewItem, depth int) {
	<details>
		{{
                       
			rawUrl := ""
			if depth == 1 {
				rawUrl = fmt.Sprintf("/system/%d", item.id)
			} else if depth == 2 {
				rawUrl = fmt.Sprintf("/central/%d", item.id)
			} else if depth == 3 {
				rawUrl = fmt.Sprintf("/department/%d", item.id)
			}
		}}
        ...

Every time the formatter ran a new newline would appear above ' rawUrl := "" '

I noticed that the Go Code Writer always adds a number of tabs depending on the indentation and then a newline ahead of the go code so I fixed the issue by trimming any leading \r \n and \t characters before writing the node, thus normalizing the string so it always starts with exactly one newline and the correct number of tabs.

@MilkeeyCat
Copy link
Copy Markdown
Contributor

I'd say this is not the right way to fix the bug, instead I'd change

var spaceOrTabOrNewLine = parse.Any(spaceOrTab, parse.Rune('\n'))

to

var spaceOrTabOrNewLine = parse.Any(spaceOrTab, parse.String("\r\n"), parse.Rune('\n'))

This space is already handled by parser

if _, ok, err = dblOpenBraceWithOptionalPaddingOrNewLine.Parse(pi); err != nil || !ok {

and it works on Linux because Linux uses \n as newline character. To fix the bug we simply have to add \r\n as potential newline character.

@davidsama
Copy link
Copy Markdown
Contributor Author

That's a good point by MilkeeyCat, my bad for not looking through the code base thoroughly enough. I have tested the change and it works fine. Commit has been updated.

@a-h
Copy link
Copy Markdown
Owner

a-h commented Dec 31, 2025

Nice change. Thanks folks. Is this a Windows only problem, hence it not showing up in the tests etc.?

@a-h a-h merged commit 25dc2ce into a-h:main Dec 31, 2025
4 checks passed
@MilkeeyCat
Copy link
Copy Markdown
Contributor

Is this a Windows only problem, hence it not showing up in the tests etc.?

Yes, only Windows uses \r\n as newline character, Linux and macOS use \n.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants