Extract Liquid.js valid and invalid variables

[SokratisVidros]

Is there a built-in way to extract Liquid.js valid and invalid variables using LiquidJS.parse?

Effectively, we are looking for a function that looks like this:

async function extractVariables (content: string): {validVariables: string[], invalidVariables: string[]} {
// Parse content with Liquid
  return {
     validVariables,
     invalidVariables
  }
}

Thank you.

[jg-rp]

I've been working on PR #770 that might do what you need.

Please could you elaborate on what you mean by "valid" and "invalid" variables?

#770 uses the term "globals" (subject to change) to mean variables that are not in scope from tags like assign and arguments passed to block tags. The idea being that you would need to compare these global variables to the variables you would pass to Liquid.render() in order to identify potentially erroneous names.

[SokratisVidros]

Hey @jg-rp, this is exactly what I am looking for. Let me know if you need help so we can merge it faster. We use Liquid.Js extensively at Novu. Currently, we have wrapped Liquid with our own logic to achieve something similar.

Currently, Liquid throws errors if an invalid syntax is used, for example, This is an example text with a {{foo..bar}} invalid example. By default, it fails fast on the first error. There is the option to get all errors simultaneously, but it would be better for DX not to fail and return two sets of liquid variables, the valid and the invalid.

Let me know if this helps.

[jg-rp]

Thanks @SokratisVidros, that helps. Understanding different use cases for retrieving variables is half the battle.

In theory, I can imagine a fault tolerant tokenizer/parser that can resume scanning a template on some syntax errors, giving us the opportunity to report multiple invalid expressions. It would be a fairly massive change though and @harttle has already raised concerns about bundle size for browsers.

[SokratisVidros]

I see. The concern about the bundle size is valid, although it can only be validated during implementation by comparing before/after bundle sizes.

For the record, we ended up with a similar in-house parser. It would be awesome if all the Liquid internals were not exposed.