[TwigComponent] Fix twig:lint bug with anonymous component tag

[smnandre]

Q	A
Bug fix?	yes
New feature?	no
Tickets	Fix #1089
License	MIT

Sincerely i'm not sure how to handle this properly "today"..

There is a lot of things i'd like to refactor in a future version, and the fact than auto-closing tags and classic ones are handled by two entirely different processes is at the top of my todo :)

But right now, i'm not sure we can do better than a quick patch, allowing the "lint:twig" to not crash for anonymous twig:Foo</twig:Foo> tags.

Timeline of what "bugs":

• the lint:twig command find all templates, and for each one create an empty template loader, then parse & compile the template
• during the parsing, the ComponentParser calls ComponentFactory::metadataFor to find the template matching the component name
• if no class-based component matches, the ComponentFactory calls the the ComponentTemplateFinder
• the ComponentTemplateFinder then asks the Loader if a matching template exists
• but as the Loader is temporary "empty".... 🐞

So we must ether:

• A) stop resolving template during the parser/compiler work
• B) ensure the TemplateFinder always contains the real "full" loader
• C) change the way the lint:twig command works

A is my long-term objective, but clearly not "today".
C is not so easy, as the corresponding code is hidden between 3 private methods

So.... first suggestion (dirty but working)

[weaverryan]

Can we, instead, replace the $environment constructor argument with $loader? We would just need a BC layer (remove the Environment type, then have an if statement that checks the type, and trigger deprecation if it is an Environmnet).

[smnandre]

Is Environment|LoaderInterface wrong ? (real question, i'm not really used to BC break handling :) )

[weaverryan]

I think that will work - I still forget we can do this now :)

[weaverryan]

I think that will work - I still forget we can do this now :)

[weaverryan]

Thank you Simon - beautiful PR