Disable `no-curly-component-invocation` rule in `octane` configuration

The no-curly-component-invocation rule in the octane configuration is creating a lot of false positives as it has no knowledge of what is a helper or component and in some cases it also flags regular {{foo}} values as components.

To avoid this unnecessary noise for Octane users we should disable the rule until we figure these issues out.

The second issue is clearly a bug, the first one can’t really be solved, but we could still use a better heuristic and e.g. consider curlies with positional args as helpers.

/cc @rwjblue @lifeart

[rwjblue]

@patocallaghan - Thanks for offering to work on it!

I think these two are “ready” for implementation work:

Do not flag invocations with positional params (straight forward to understand) Do not flag ambiguous mustaches as component invocations

Then we can see where things settle and decide if we need another config option for strict (it’s still not 100% clear what this would mean, so fixing the first two would help clarify).

in this context what does ambiguous look like?

Ambiguous specifically means:

A MustacheStatement (does not apply to BlockStatements as they are never ambiguous), with no positional arguments and no named arguments. They would look like:

{{foo}}

[patocallaghan]

@rwjblue I’ve finally got some time to work on these fixes. I just have a clarification question.

We previously shipped a fix in https://github.com/ember-template-lint/ember-template-lint/pull/861 which implemented the following logic:

We could tweak things a bit so that the rule does not apply to block params when used without any arguments (e.g. {{foo}} vs either {{foo whatever}} or {{foo some=thing}}).

So this slightly contradicts the feedback above (or maybe it doesn’t 🤔)

Do not flag invocations with positional params (straight forward to understand)

Does the change I’m making here, Do not flag invocations with positional params apply to be block params and non-block params, or just to non-block params? Do I need to refactor the previous change we shipped?