My project is currently structured such that the HTML templates are in the root of the project within a templates/ directory.
My HTTP request handlers are several levels down the file system tree.
go.mod
templates/webpp/*.html
templates/admin-dashboard/*html
cmd/webapp/main.go
cmd/admin-dashboard/main.go
app/webapp/handlers/handler.go
Ideally, I would like to be able to use go:embed in the following way:
//go:embed ../../templates
or
///go:embed $PROJECT_ROOT/templates
But unfortunately neither of these methodologies exist. The go doc embed says:
The patterns are interpreted relative to the package directory containing the source file. The path separator is a forward slash, even on Windows systems. Patterns may not contain ‘.’ or ‘..’ or empty path elements, nor may they begin or end with a slash.
I could relocate the templates (something I'd rather not do since in some modes my webapp expects to see them relative to the running binary). e.g.
webapp <-- binary uses templates at runtime
templates/*.html <-- editable HTML files
So I could have my build script copy them in place just before compilation, but this seem unnecessarily convoluted; if I bypasses the build script or forget or mess up the build sequence, I could end up with a v2 binary with v1 "old templates" embedded.
Or, I could make the templates/ directory into a package and export an embed.FS and then inject it as a dependency to my application, but now my code is re-structured just to accomodate the embedding process.
Is there any likelyhood that go:embed will allow some type of embedding relative to the project root in future, or would this raise security issues?
go:embed is a great feature, but it feels like I'm beholden to it- either forced to copy, relocate, split up my sets of templates into separate directories or adjust my application to use dependency injection.
What's the best practice?