feat: update ECS config and apply standards

[nlemoine]

Bump ECS config.

Note it changed quite a lot a files and we might want to add this commit in the .git-blame-ignore-revs file.

It also removed to full namespace from the docblocks, I don't if this cause issues when generating API reference? @gchtr

[Levdbas]

I see we are no longer prefixing the docblock return types with the full namespace. Could this have a negative impact in the symbol discovery of IDE's?

[nlemoine]

No, since they're referenced in imports:

timber/src/Factory/PagesMenuFactory.php

Line 5 in 77bdbdb

use Timber\CoreInterface;

I just wonder if the doc generation tool is able to compute the FQCN or is it parsing the doc block as is, example:

[Levdbas]

I've just tested the doc generation in combination of your branch and the docs still seem to compile the correct paths :)

[Levdbas]

I suggested some docblock updates while at it and there is one return type issue that we might already discussed in a ticket. Just checking. Other than that, looks good to me.

[Levdbas]

This throws a static analysis error. Is this something we must take care of? Not sure if this was something that we already discussed in an issue.

[Levdbas]

@gchtr , mentioned this over here: #2668

[nlemoine]

Haven't figured it out yet but this shouldn't prevent us from merging the PR. We don't require PHPStan to pass (yet). :)

[Levdbas]

@gchtr , can you take a final look at this?

[gchtr]

It also removed to full namespace from the docblocks, I don't if this cause issues when generating API reference? @gchtr

It’s not a problem, because the reflections still work and generate fully qualified names, apparently.

It only doesn’t work for hook documentation. There, the types have to be generated from the DocBlock. As you can see in the following screenshot, we could have Post or Environment, but wouldn’t know whether this comes from Timber or Twig.

These hook DocBlocks are parsed by looping over the tokens in https://github.com/timber/teak/blob/a5af1504cadb8e5d2277069165caf948d1d0c012/lib/Compiler/HookReference.php#L62-L70. I guess I could somehow also derive the types from the variables that are present before a hook appears. I’ll have to check this out. I created an issue for this in timber/teak#3.

For now, I think it’s a tradeoff we can live with, because it only affects some few filters in https://timber.github.io/docs/v2/hooks/filters/.

[nlemoine]

Thanks @gchtr for the details about doc generation. There should be a way to grab the FQCN, let me know if I can help.