error locations and IDE diagnostics support

[OmarTawfik]

Thank you for the awesome crate. I have been slowly integrating it in a few projects, and it is proving to be incredibly useful.

However, one thing that we are struggling with as this scales up is debugging errors when a variable/functios is renamed or removed. Our solution right now is to panic!("{tera_error}"), rerun the build in CLI, and read through the build logs.

It would be great if we can thread these diagnostics to the editor directly. For example, projects can easily print these errors information (message, file, line, column) on stdout, and VS Code will pick it up and render it diagnostics/squiggly lines. Large projects often define multiple matchers for different frameworks they are using:

But unfortunately doing so for Tera (like the example above) is proving to be difficult, since there is no consistent output format for these errors, and not all of them include the relevant information. I wonder if this is something that can be added/supported in Tera, so that users can propagate it correctly?

For example, file/range information can be added to tera::Error:

#[derive(Debug)]
pub struct Error {
    pub kind: ErrorKind,

    pub file: Option<PathBuf>,
    pub range: Option<Range<LineColumn>>,

    source: Option<Box<dyn StdError + Sync + Send>>,
}

Thank you!

[Keats]

That's coming in v2! Have a look at an error: https://github.com/Keats/tera2/blob/master/src/tests/snapshots/tera__tests__rendering__rendering_errors%40unknown_var.html.snap.
Can VSCode read that file/line/col format? I can change it

[OmarTawfik]

Great news! thank you!
What is the timeline for a beta/preview release of v2?

re: the format: VS Code matchers are just regex with capture groups. So, I think we have two options here:

1. Have an output format that is really easy to parse, for example, all the above values joined by a common separator (:):

// A problem matcher definition in VS Code:

{
  "fileLocation": ["relative", "${workspaceFolder}"],
  "pattern": {
    // foo/bar.jinja2:10:1:10:22:error:Failed to parse this expression.’
    "regexp": "^([^:]+):([^:]+):([^:]+):([^:]+):([^:]+):([^:]+):(.+)$",
    "file": 1,
    "line": 2,
    "column": 3,
    "endLine": 4,
    "endColumn": 5,
    "severity": 6,
    "message": 7,
  }
}

2. Or the more configurable/extensible option, exposing these properties on the error types returned, and the user can format/print it however they think is useful. So that Tera doesn't need to be forced to support a specific format, or worry about breaking it in the future.

[Keats]

What is the timeline for a beta/preview release of v2?

No timeline yet. I'll try to add functions/tests/filters soon so people can try with some real templates but can't say when I will have time

[OmarTawfik]

Thank you for your efforts!