Templ generate for dependencies

[mattd-cg]

I would like to create separate modules which provide their own ui. These will then be aggregated and consumed by a couple different apps which mainly focus on the orchestration of a select few modules.

If possible, I would like to avoid checking in the generated code to the modules' repo. Instead, it would be preferred to generate all of the code for the primary app's dependencies during it's CI/CD process.

Is there a known/preferred way to do this, or even a reason not to do this and an alternative approach?

[joerdav]

Hi, thanks for the question. Personally I haven't considered this, I always commit my generated code, as is best practice in general for go modules.

I have been thinking of this and haven't thought of a good solution for you, as the go module system doesn't really support extra build steps just for deps.

In short I think you would be taking on a lot of complexity just to keep generated files out of your repo.

[mattd-cg]

Thanks for your consideration, and I believe you are correct. I continued to explore various options such as workspaces which included the dependency and git check-in rules. However it seems it's too complex to be valuable, so just going to check-in the generated code.

[jtom38]

@mattd-cg I created a component library for Templ for personal use. The problems are as you defined. Go get will download the project but you are unable to generate the templates can use them. I tried to compile and upload and it would not find the functions. So I have moved to a git submodule. Is this ideal? nope but it works. Just remove the go.mod and go.sum files and let them become part of your project.

I want to see if I can make a script that will check the go.mod for dependencies and review all the directories for *.templ files. If it finds them, templ generate. Then see if I can find the components in my project.

[a-h]

It's hard to say without a code example, but generally, if you can't use functions in a Go module you've created, it's because you've named your components templ withALowerCase() instead of templ WithAnUpperCaseLetterAtTheStart().

Go uses the casing of function names to determine whether they're "exported" or not.

[jtom38]

Here is my repo if you want to take a look.

https://github.com/jtom38/templ-bulma

I use all public function naming per the Go standard. So anything that starts with a lower case name would be private within the library. That is the expected behavior.

My purpose for this was to have a external dependency to make building sites faster for me given I don't always remember all the bits that are needed for some html elements. Plus it was a fun test to see what could be done. :)

[a-h]

Looks good. These days, I'd usually expect to see a go.mod file and the generated files in the repo, so that it's a standard Go module, rather than using git submodules, which is what people did (had to do?) before Go modules was a thing.

If you're not familiar with Go modules, if you rename your repo as bulma (so you don't always have to alias it, because hyphens aren't allowed in the last part of Go modules), run go mod init github.com/jtom38/bulma in the repo to create a go.mod file, then add any required dependencies (e.g go get github.com/a-h/templ), run templ generate to create the output code, check it builds with go build ./..., then commit and push, you'll have a reusable library that you can import it from other projects using the Go module system.

In a project that you want to import the library from another module (project), you run go get github.com/jtom38/bulma in that project, add import github.com/jtom38/bulma to the top of your templ file, and then your components are accessible as @bulma.Container("breakpoint").

I covered the process for making a reusable library at one point in this talk at Big Sky DevCon 2024: https://www.youtube.com/embed/uVKSmR_hBMs?si=yacWP-H43ib_J2d4&start=7635

If you don't like the way that Go modules means more steps in updating the code (go to library repo, make change to code, commit/push, go to consumer code, run go get -u github.com/jtom38/bulma), people typically use the replace directive or go.work file to point their local env to specific directories.

[jtom38]

I wrote all these components in my first project and used them within a single repo. Everything worked just fine and no issues. But when I wanted to reuse all my components in a second project I moved it all into its own repo with a go.mod. I was able to import the package with go get but when I ran templ generate it didn't find them to compile.

I tried to have the go.mod file with *.templ files but it did not generate the files as expected from my main project. I have noticed the VSCode does not find the components till it gets generated. I might need to manually import the package and then add a component without intellasence and try to generate and see if that works.

I tried to have compiled template files in the package also, but did not work. I was not a fan of this idea because my thinking was it would be better to have the template generated by each project using them so the templ version would not become a hard dependency. If someone wanted to use it, I wouldn't want to force them into the templ version that compiled the artifacts.

So I did some testing and running it as a git submodule without a go.mod worked as I expected.

I will watch the video to see what I might be missing to make external component package. I have a couple more things to test.

Thank you for your time!

[jtom38]

@a-h Just wanted to say thank you for linking the video. It cleared up my problem and I was able to add go.mod support back into the package!

I am unsure what happened with my initial tests creating the package but it now works.

Thank you for all the effort you put into templ! I love this package and makes frontend much more enjoyable for me!