refactor: update templ generate to support pwd being a symlink

[mlhetland]

Before you begin

Please make sure you're using the latest version of the templ CLI (go install github.com/a-h/templ/cmd/templ@latest), and have upgraded your project to use the latest version of the templ runtime (go get -u github.com/a-h/templ@latest)

Done.

Describe the bug

A clear and concise description of what the bug is.

templ generate does not work when the current directory is accessed via a symlink.

To Reproduce

A small, self-container, complete reproduction, uploaded to a Github repo, containing the minimum amount of files required to reproduce the behaviour, along with a list of commands that need to be run. Keep it simple.

https://github.com/mlhetland/templ-symlink-bug

To reproduce:

$ cd templ-symlink-bug/hello-world-symlink
$ templ generate

Expected behavior

A clear and concise description of what you expected to happen.

The appropriate …_templ.go file should be generated.

Screenshots

If applicable, add screenshots or screen captures to help explain your problem.

templ info output

Run templ info and include the output.

Doesn't seem to be a recognized command? Anyway, the output is:

usage: templ <command> [<args>...]

templ - build HTML UIs with Go

See docs at https://templ.guide

commands:
  generate   Generates Go code from templ files
  fmt        Formats templ files
  lsp        Starts a language server for templ files
  version    Prints the version

Desktop (please complete the following information):

• OS: MacOS
• templ CLI version: v0.2.747
• Go version: go version go1.22.0 darwin/arm64
• gopls version: golang.org/x/tools/gopls v0.16.1

Additional context
Add any other context about the problem here.

One can see a bit more about what happens by running templ generate -v in both the symlinked directory and the actual directory:

$ cd templ-symlink-bug/hello-world-symlink
$ templ generate -v
(✓) Starting post-generation handler
(✓) Walking directory [ path=/Users/mlh/templ-symlink-bug/hello-world-symlink devMode=false ]
(✓) Starting event handler
(✓) Dev mode not enabled, process can finish early
(✓) Post-generation event channel closed, exiting
(✓) Waiting for push handler to complete
(✓) Waiting for event handler to complete
(✓) Waiting for post-generation handler to complete
(✓) Complete [ updates=0 duration=212.375µs ]
$ cd ../hello-world
$ gempl generate -v
(✓) Starting post-generation handler
(✓) Starting event handler
(✓) Walking directory [ path=/Users/mlh/templ-symlink-bug/hello-world devMode=false ]
(✓) Dev mode not enabled, process can finish early
(✓) Processing file [ file=/Users/mlh/templ-symlink-bug/hello-world/hello.templ ]
(✓) Generated code [ file=/Users/mlh/templ-symlink-bug/hello-world/hello.templ in=1.010083ms ]
(✓) Post-generation event channel closed, exiting
(✓) Waiting for push handler to complete
(✓) Waiting for event handler to complete
(✓) Waiting for post-generation handler to complete
(✓) Complete [ updates=1 duration=1.3935ms ]

[a-h]

Interesting. The templ generate command uses a simple filepath.WalkDir to walk the tree:

templ/cmd/templ/generatecmd/watcher/watch.go

Lines 38 to 55 in a48e910

	func WalkFiles(ctx context.Context, path string, out chan fsnotify.Event) (err error) {
	return filepath.WalkDir(path, func(path string, info os.DirEntry, err error) error {
	if err != nil {
	return nil
	}
	if info.IsDir() && shouldSkipDir(path) {
	return filepath.SkipDir
	}
	if !shouldIncludeFile(path) {
	return nil
	}
	out <- fsnotify.Event{
	Name: path,
	Op: fsnotify.Create,
	}
	return nil
	})
	}

WalkDir's docs state that it doesn't follow symbolic links: https://pkg.go.dev/path/filepath#WalkDir but without explanation. The explanation is provided in golang/go#4759 (comment) where it's noted that following symlinks could result in a traversal that loops and therefore never finishes.

However, I note that fs.WalkDir seems to be newer than filepath.WalkDir, and supports having the base directory (only) be a symlink - https://pkg.go.dev/io/fs#WalkDir - and that there's also some additional work ongoing to support optionally following symlinks in golang/go#49580

So, I think that it's likely that replacing filepath.WalkDir with fs.WalkDir is the answer to this issue, in that it supports a base directory being a symlink. Supporting nested symlinks would have to come later (if required at all), following golang/go#49580

[a-h]

This is a good first issue for someone to pick up.

The hardest part of this is testing - an integration test would need to run a templ generate out of a symlinked folder.

The https://github.com/a-h/templ/tree/main/cmd/templ/testproject package provides a way to run integration tests on a sample project. If you see where that's used in the code, you can find some examples.

Otherwise, I'll get to this when I get to it...

[mlhetland]

Until it’s fixed, in case anyone else is having trouble with this – you could add cd $(realpath .) or the like to your build, before running templ.