Can reveal/reveal-latte be used in a project that doesn't use nette/application?

[ZebulanStanphill]

In my project, I'm trying to use Latte templates without any of the rest of the Nette libraries; specifically, I'm not using Nette Application at all. I simply render Latte templates via \Latte\Engine#renderToString in my own custom classes.

I'm using {templateType} alongside classes with typed parameter constructors, so hypothetically, it should be possible for a PHPStan extension to find the .latte files, lookup the matching class, and verify that the parameters line up in number and type.

However, after installing reveal/reveal-latte and running PHPStan, it doesn't seem to have any effect. Yes, I made sure that phpstan/extension-installer was working, and I even manually added all the rules to my PHPStan config like so:

services:
	#-
	#	class: Reveal\RevealLatte\Rules\LatteCompleteCheckRule
	#	tags: [phpstan.rules.rule]
	-
		class: Reveal\RevealLatte\Rules\NoNetteRenderMissingVariableRule
		tags: [phpstan.rules.rule]
	-
		class: Reveal\RevealLatte\Rules\NoNetteRenderUnusedVariableRule
		tags: [phpstan.rules.rule]

EDIT: turns out that since Reveal\RevealLatte\Rules\LatteCompleteCheckRule is auto-registered by phpstan/extension-installer, it should not be registered again in your config - doing so will cause it to crash. See #12.

Is my use case supported by reveal/reveal-latte? If so, what am I doing wrong; and if not, could the plugin be updated to support my use case? The docs for the plugin aren't really clear on this to me.

Side note: should issues and/or PRs for reveal/reveal-latte be submitted here or https://github.com/revealphp/reveal-latte?

[TomasVotruba]

Hi, this is a monorepo, so submitting project issue here is the way 👍

The functionality depends on LatteCompleteCheckRule. That hooks on template holders:
https://github.com/revealphp/reveal/tree/main/packages/reveal-latte/src/LatteTemplateHolder

We use thiese only on Nette application, so you'd have to check those template holders if they match your template usage.

[ZebulanStanphill]

The way I'm using Latte can basically be boiled down to:

CoolTemplate.latte:

{templateType My\Stuff\CoolTemplate}
<div>{$foo}</div>

CoolTemplate.php:

<?php declare(strict_types=1);
namespace My\Stuff;

final class CoolTemplate {
	public function __construct(
		public string $foo,
	) {}
}

some-other-spot-in-the-code.php:

<?php declare(strict_types=1);
namespace My\Stuff

final class Whatever {
	public static function doThing(): string {
		$latte = new \Latte\Engine();
		$latte->setTempDirectory('/my-temp-folder-path');

		return $latte->renderToString(
			__DIR__ . '/CoolTemplate.latte',
			new CoolTemplate(
				foo: 'bar'
			)
		);
	}
}

After taking a look at the template holders, it appears that none support this way of doing things.

---

Notably, after changing something (or maybe I just wasn't testing right earlier), PHPStan now fails as long as the Reveal\RevealLatte\Rules\LatteCompleteCheckRule rule is included in my PHPStan config. See #12 for more details.

[TomasVotruba]

Could you add this as a test case here!?
https://github.com/revealphp/reveal/tree/main/packages/reveal-latte/tests/Rules/LatteCompleteCheckRule

[ZebulanStanphill]

Yeah, I think I can try and submit a PR to do that. One question, though: what's the difference between the stuff in the "Source" folder versus the "Fixture" folder? I don't really understand the organization here.

[TomasVotruba]

The Source are classes autoloaded with PSR-4, that are needed for fixture to run = everything around.

The Fixture is the minimalistic test case, that you need to verify. Usually 2-5 lines = the core.

[lulco]

Maybe we should just add Latte\Engine to NetteTypeAnalyzer::TEMPLATE_TYPES?

[lulco]

Maybe we should just add Latte\Engine to NetteTypeAnalyzer::TEMPLATE_TYPES?

I've check this and it will not be enough with your use case. You use Latte\Engine::renderToString in way I've never seen and I event didn't know it is possible :)

[ZebulanStanphill]

@lulco Is the blocker the usage of an object to provide the template arguments? Would chaning NetteTypeAnalyzer::TEMPLATE_TYPES be enough to support using \Latte\Engine::renderToString when arguments are provided as an associative array?

(If so, that's pretty ironic, since the point of the templateType feature is better IDE integration and type checking. 😛)

@TomasVotruba I've opened #18 to add tests for the "\Latte\Engine::renderToString with arguments as array" use case.

[lulco]

Is the blocker the usage of an object to provide the template arguments?

For now, yes. We need to implement it.

Would chaning NetteTypeAnalyzer::TEMPLATE_TYPES be enough to support using \Latte\Engine::renderToString when arguments are provided as an associative array?

Probably yes, we need to test it.

(If so, that's pretty ironic, since the point of the templateType feature is better IDE integration and type checking. 😛)

You can still use {templateType} in your latte files, it is just for IDE, it is ignored by compiler and also by reveal static analysis.

@TomasVotruba I've opened #18 to add tests for the "\Latte\Engine::renderToString with arguments as array" use case.

Thanks, we will check it :)