Make it possible to turn off `OptionalDependencies` in `StubbedEnvironment`

[ruudk]

First of all, thanks for this amazing tool! 👏

In our Symfony project we use a custom translation mechanism. We don't want people to use the default trans blocks and functions.

But these are automatically added because the classes exist:

https://github.com/VincentLanglet/Twig-CS-Fixer/blob/1f1bcc5b7a608c64603e8d3a879508316bfc9919/src/Environment/StubbedEnvironment.php#L128-L133

It would be great if I could turn off this behavior. What would be the best way?

Maybe introduce an option on the Config that's enabled by default, that we can disable?

Then I can manually add all the required token parsers myself.

I could create the PR if you tell me how you want it to be done 😊

[VincentLanglet]

In our Symfony project we use a custom translation mechanism. We don't want people to use the default trans blocks and functions. But these are automatically added because the classes exist:

Hi, I'm not sure about your use case.

If the classes exists, it seems natural that the linter are using them, since the twig/html is valid.

Shouldn't the job of

• A special rule to check you are now using trans block name or function.
• The Symfony linting tool https://symfony.com/doc/7.2/templates.html#linting-twig-templates, which will report an error if you didn't register those block/functions and are using them.

For the special rule, trans block will be a Token::BLOCK_NAME_TYPE and function will be Token::NAME_TYPE.

[ruudk]

Interesting.

It would be great if I could create a rule for Twig CS Fixer that produces a non fixable error when using a forbidden block/function/filter. We could create a generic disallow rule that you can configure yourself. WDYT?

[VincentLanglet]

It should be possible. I'm interested.

Maybe the best would be to have three rules: Forbiddenblockrule Forbiddenfunctionrule Forbiddenfilterrule

[VincentLanglet]

The ForbiddenBlockRule will be easier since there is a special token "block name" for this.

But for function and filter, it could be interesting to improve the Tokenizer/Lexer because the "Token::Name_Type" is used for at least variable, function and filter...