Add a handlebars linter to check for undefined variables in hooks

[moretea]

How to reproduce

• create a package (or pick an existing one)
• create or modify hooks/run to contain:

   {{nonense_var_name}}
  

Expected output

error message

Actual output

Silent error; this variable is rendered as an empty string.

[reset]

This behaviour is coming from our handlebars renderer. Undefined variables don't result in rendering errors in handlebars, so they're happily rendered in our configuration and hook files as well. We could fork the handlebars renderer or add our own, but the behaviour of the if block would change. undefined and null are two of the falsey representations to handlebars.

I think I'd rather have the application fail instead of the renderer. @habitat-sh/habitat-core-maintainers what do you guys think?

[smith]

I'm in agreement with @reset for another reason: TOML doesn't have nil, so if you want something to not be set you either would have to use an empty string, which is not falsy, or false, which would probably require too much explanation ("use a string if present, or false without quotes if not present".)

I would prefer if it worked like the original suggestion, but it seems we would be fighting against the underlying technologies for a small benefit.

[smurawski]

As as noted, we're using a handlebars rendering library and having it check for empty references would be a major change to the library.

We could probably address this in a linting tool that could inspect the template, the required pkg_binds, and the default toml and look for any undefined references in the config templates.

[bixu]

Recently had a conversation with @adamhjk about linting templates. Having a linter would have the nice side effect of catching errors around changing syntax at build time instead of at runtime (which in a recent case at $job would have saved me a few days of frustration).

[qubitrenegade]

I vote the name of the linter be roomba so I can hab studio roomba

[christophermaier]

There is a strict mode in the handlebars library we're using. However, it was added in version 0.32.0 and we are currently stuck on version 0.28.3 for fun reasons

However, @mwrock is currently doing work to extract the core templating logic from the Supervisor into the core crate. I think that work will begin to allow us to move forward with updating our handlebars dependency, and will also make it easier to provide an external linter.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[qubitrenegade]

any thoughts...? I think this is important...

…

On Thu, Apr 2, 2020 at 7:11 PM stale[bot] ***@***.***> wrote: This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1779 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADSBHCP3JJTWSEJWZRKHM73RKUZSTANCNFSM4DAMC2IA> .

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We value your input and contribution. Please leave a comment if this issue still affects you.

[stale]

This issue has been automatically closed after being stale for 400 days. We still value your input and contribution. Please re-open the issue if desired and leave a comment with details.