You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using it to generate log output according to the installation's configuration. We deploy to various environments and how they parse/understand the log entries differs.
The issue is that the actual template is provided by configuration and we need to provide each of the variables in a bunch of possible styles: strings in uppercase, lowercase, and, possibly, title case; numbers might need rounding; dates might need manipulation (ie. as a unix timestamp vs. ISO 8601 timestamp vs. Windows timestamp, etc.).
I would NOT suggest allowing code to be embedded inside the template as that would pose a security risk unless you added a lot of complexity (ie. using a library to sanitize the code so that only a subset of features could be used).
However, the parse function COULD accept a list of transforms.
I would propose the following, given by example:
consttemplate=parse({severity: '{{logLevel:default->toUpperCase}}'},{string: {toUpperCase: (val)=>val.toUpperCase(),toLowerCase: (val)=>val.toLowerCase()},number: {round: (val)=>Math.round(val)}});// template.keys => typical stuff// template.transforms => the second parameter passed to parseconstresult=template({logLevel: level})
If a PR were submitted for this, would it be accepted?
The text was updated successfully, but these errors were encountered:
Would you have issues if I pull in the typings, from @types/json-templates? It would mean that this package's maintainers would have to take-over the maintenance of those definitions. I know several other projects have done this to make it easier to keep the definitions in sink with the library.
Great library!
I am using it to generate log output according to the installation's configuration. We deploy to various environments and how they parse/understand the log entries differs.
Here is what we are doing:
The issue is that the actual template is provided by configuration and we need to provide each of the variables in a bunch of possible styles: strings in uppercase, lowercase, and, possibly, title case; numbers might need rounding; dates might need manipulation (ie. as a unix timestamp vs. ISO 8601 timestamp vs. Windows timestamp, etc.).
I would NOT suggest allowing code to be embedded inside the template as that would pose a security risk unless you added a lot of complexity (ie. using a library to sanitize the code so that only a subset of features could be used).
However, the parse function COULD accept a list of transforms.
I would propose the following, given by example:
If a PR were submitted for this, would it be accepted?
The text was updated successfully, but these errors were encountered: