Proposal: Exposing and Extending Sourcemaps for external tooling

[whalenrp]

Templ has long supported sourcemapping as part of the built-in LSP integration, but sourcemaps themselves are very useful for other tools as well. In my case, I'd like to build code coverage tooling for templ by mapping the generated go coverage profiles back to their original ranges. Other features could include mapping stack traces back to their original lines rather than generated ones. However right now there are a few challenges:

• The sourcemaps are incomplete and don't cover constructs that aren't necessary for the LSP
• Generate() can be called directly to get a sourcemap in memory, but it's not available as an output of calling templ generate, meaning you rely on two separate runs of code generation to get the sourcemap data.
• Even with the sourcemap accessible in memory, format.Source is called on the source after it's generated, which makes the lines in the sourcemap inaccurate.

What's great though is that a lot of the heavy lifting has already been done as a result of the Range additions started from this discussion, so the first is mostly a matter of registering ranges in the sourcemaps. So really I'm curious what folks think about a few changes to the generation logic:

1. Add a -sourcemap flag to templ generate that writes a *_templ.map file with the sourcemap contents. A format like the following is one possible approach:

{
  "version": 1,
  "sourceFile": "foo.templ",
  "targetFile": "foo_templ.go",
  "mappings": [
    {
      "source": { "startLine": 10, "startCol": 5, "endLine": 10, "endCol": 22 },
      "target": { "startLine": 25, "startCol": 3, "endLine": 25, "endCol": 20 },
    }
  ]
}

2. When set, also skip the formatting of the generated templ output. We could do this with feat: add -no-format flag to skip formatting on generated output #1409 or combine the formatting changes with the -sourcemap flag above.
3. Register Ranges to the existing Sourcemap, skipping anything that's already registered for the LSP to avoid any regressions there.

Thoughts?
Is this something you guys would be open to? If so, what do you think about the proposed file format above?
Do you have any opinions on the file naming or command line arguments?