❗Allow plugins to modify Config::$fileExtensions early

[ohader]

ProjectAnalyzer consumed Config::$fileExtensions early in its
constructor - without having processed plugins' modifications,
registering their custom scanners or analyzer implementations.

This change

• adds new specific interface \Psalm\Plugin\FileExtensionsInterface
  to be used by plugin implementations
• extracts file extension handling from \Psalm\PluginRegistrationSocket
  and interface \Psalm\Plugin\RegistrationInterface to a new dedicated
  \Psalm\PluginFileExtensionsSocket and new interface
  \Psalm\Plugin\FileExtensionsInterface
  !!! this is a breaking change in PluginRegistrationSocket !!!
• adds runtime in-memory cache for Config::$plugins
• calls new method Config::processPluginFileExtensions(), providing
  modifications to file extension only early in ProjectAnalyzer
• adjusts documentation

Adjusted test scenario https://github.com/ohader/psalm-6788/tree/adjusted

Fixes: #6788

---

Deprecation in 4.x branch, see #7455

[ohader]

Okay, CI-wise

• labels needs to be assigned to this PR (I guess I cannot declare that in a commit or PR description)
• test-with-real-projects: looking into https://github.com/psalm/endtoend-test-psl/blob/1.6.x/tools/psalm/psalm.xml, failures don't seem to be related to this very PR here

[orklah]

failure is indeed unrelated.

If this is a breaking change, I'm afraid this will have to wait for Psalm 5

[ohader]

failure is indeed unrelated.

Thanks for picking this up so fast!

If this is a breaking change, I'm afraid this will have to wait for Psalm 5

In case somebody called the functionality of addFileTypeScanner or addFileTypeAnalyzer already in their custom plugins' __invoke() method , it will cause a PHP fatal error since the methods have been moved.

As a non-breaking (but also non-functional) fall-back I could think of keeping empty stub methods still in PluginRegistrationSocket, in particular keeping

• https://github.com/vimeo/psalm/pull/6789/files#diff-4f7069bc1517a30222c4a3e6936ff00dcb9234ed75a215dc14ea7c93d30c4e52L126
• https://github.com/vimeo/psalm/pull/6789/files#diff-4f7069bc1517a30222c4a3e6936ff00dcb9234ed75a215dc14ea7c93d30c4e52L162

[orklah]

Yeah, this might be better if you want to ship this soon. Please add a deprecated tag so we know to remove it on Psalm 5

[orklah]

Hi @ohader, just a friendly notice: Psalm 5 will be coming soonish. If you want to have a chance of getting this merged before Psalm 6, deprecation should be commited on 4.x branch, this already targets master so it should be okay.

[ohader]

@orklah thanks for the notification. Can you please give me a hint how deprecations are handled (error trigger, documentation, etc) in Psalm? Thx in advance!

[orklah]

flag any removed method/property/class as @deprecated with a description. If it's not a full removal, just add some phpdoc to explain the change.

In any case, UPGRADE.md need to be updated on master branch to explain each BC break

[ohader]

@orklah

• deprecation change is here !!! Deprecate \Psalm\Plugin\RegistrationInterface methods #7455
• I've manually rebased this very PR and extended UPGRADING.md

[ohader]

Not sure what the idea behind Use of numeric literal separator is required was, but... 1_635_800_582 seems to work... it's actually just a unix-timestamp to have unique identifiers for exceptions...

[ohader]

@orklah Concerning release of Psalm v5: Is there a schedule/date yet? I might have some smaller changes/fixes and would focus on them during the weekend...

[orklah]

@ohader we were thinking about releasing an alpha in the next few days but it doesn't mean feature freeze yet. We still have a few weeks before release date, however we don't have a precise schedule

[orklah]

Can you rebase and ping me? I'll merge this

[ohader]

@orklah Rebased. My brain was busy with totally unrelated tasks during weekdays, sorry for the delay.

[orklah]

Thanks!