Add option to treat missing variables as errors #53
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previous behavior was to just return a string which was either the rendered template or the value of err.Error(). Callers can now explicitly handler errors. This is a breaking change to the API.
It's an error if you try to render a missing variable, but it's acceptable to check for its existence
Add support for examining the parsed tags
Roughly 40% of the tests are failing at this point, and have been disabled :(
Fetching golint is failing due to the Travis CI containers being rate limited by go.googlesource.com
fix(isEmpty): Ignore empty strings on list iteration.
This confirms the fix in #7
This adds an extra function `FRender` that accepts an io.Writer as its first argument in order to support direct writing to some sink. The name has been chosen for consistency with the fmt package.
This adds support for rendering layouts directly to an `io.Writer`.
Support rendering directly to an io.Writer
…of the interface)
…-for-sections Fix building context stack for inner elements of sections
This also changes the spec_test behavior to make tests opt-out rather than opt-in as nearly all are passing.
Update mustache/spec submodule to latest
…-false-value-sections
…sections Fix rendering non-false value sections
Exposes a missing variable control to the command-line to allow render to fail on missing variables `--allow-missing-variables=false`.
…ssing-vars mustache: expose missing variable control
Migrate to github actions and un-vendor golangci-lint.
Update Golang and packages to latest versions
Experimental support for lambda sections
The manual page at mustache/mustache moved to GitHub pages
As a library user, we needed a way to translate error messages coming from the library. This pull request introduces a way to let library users customize error messages if they want. It is as well fully retro-compatible as it doesn't change the current error messages. What the pull request changes: * Make the error type public * Add an error code to let library users identify the error reason * Add a `Reason` attribute for errors cases that need the name of the entity generating the error * Make the `Line`, `Code` and `Reason` attribute public to let library users customize (translate) error message * Keep the current error messages
Otherwise errors are not shown on term when redirecting stdout to a file.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a breaking change as it changes the API to follow the idiomatic Go convention of returning errors.
I don't expect it to be merged since the project does not appear to be maintained, just sharing in case anyone else is looking for this functionality.