Change https://golang.org/cl/301493 mentions this issue: text/template/parse: add mode to skip func-check on parsing

Change https://golang.org/cl/301493 mentions this issue: text/template/parse: add a mode to skip func-check on parsing

I was looking into this and noticed that Goland has IDE-level support for this. It requires the use of a comment to specify the embedded type.

{{- /*gotype: package/import/path.type_name*/ -}}.

I can't see a way to support language features without some sort of "type hint" for template files, so maybe this is something to consider making standard.

https://blog.jetbrains.com/go/2018/12/14/go-templates-made-easy/

@a-h it actually works quite nice even without these magic comments. I never used them. It has almost everything you expect when working with html templating languages out of the box.

Has there been any discussion what the default template file extensions should be?

I currently see the following suggestions in VS Code:

• Go Template File - tmpl
• Golang GO Template - gogo
• Golang HTML Template - gohtml
• Golang Java Template - gojava
• Golang JavaScript Template - gojs
• Golang JSON Template - gojson
• Golang PHP Template - gojava
• Golang Text Template - gotemplate
• Golang TypeScript Template - gots
• Golang YAML Template - goyaml

I think this is not the optimal approach. It would be more flexible to use a single extension to indicate that a file is a Go template with a pattern like filename.ext.gotmpl.

AFAIK all template files are text templates for Go with the exception of html. Extension scheme I proposed makes it obvious what the template filename should be and identifies go template files uniquely - .tmpl extension has other uses.

It should be configurable. In most of projects we used *.html for go templates. Once I saw .gohtml. And absolutely never .tmpl.

There actually was an issue where I mentioned these concerns @harvastum. It was quite some time ago, it may also be in old repo (which was owned by Microsoft at the moment).

Has there been any discussion what the default template file extensions should be?

I currently see the following suggestions in VS Code:

* Go Template File - `tmpl`

* Golang GO Template - `gogo`

* Golang HTML Template - `gohtml`

* Golang Java Template - `gojava`

* Golang JavaScript Template - `gojs`

* Golang JSON Template - `gojson`

* Golang PHP Template - `gojava`

* Golang Text Template - `gotemplate`

* Golang TypeScript Template - `gots`

* Golang YAML Template - `goyaml`

I think this is not the optimal approach. It would be more flexible to use a single extension to indicate that a file is a Go template with a pattern like filename.ext.gotmpl.

AFAIK all template files are text templates for Go with the exception of html. Extension scheme I proposed makes it obvious what the template filename should be and identifies go template files uniquely - .tmpl extension has other uses.

I agree this is certainly the most flexible, but can VS Code do something like layered syntax parsing where it is able to work with Go template syntax and YAML at the same time without creating a new language definition?

It should be configurable. In most of projects we used *.html for go templates. Once I saw .gohtml. And absolutely never .tmpl.

Yes, it obviously should be configurable. But defaults are powerful. People will use them, they will become convention and at some point, standard. This choice is pretty important.

This has soaked for a while as an experimental feature, and we should make it default.

But it sounds like we should expose some additional configuration before turning it on by default. @pjweinb WDYT?

what extra configuration?

Just the file extension(s). Per @inliquid's #36911 (comment):

It should be configurable. In most of projects we used *.html for go templates. Once I saw .gohtml. And absolutely never .tmpl.

FWIW, I've seen all of those, including .tmpl. I think .tmpl or .gohtml is probably fine as a default, but it should be possible for users to configure it for codebases using different file extensions.

I suppose this doesn't need to block templates being enabled by default, since users can always disable if it doesn't work for them.

@pjweinb does that make sense? Any other concerns before moving this out of experimental?

Change https://golang.org/cl/363360 mentions this issue: gopls: template suffix flags and documentation