Enable extensions based on composer.json instead of those loaded at runtime (fixes #5482).

[AndrolGenhald]

No description provided.

[AndrolGenhald]

I'm not sure how to make this only available in 7.2, I'd rather not make a whole new stub file, but it doesn't look like psalm supports @since? Not immediately necessary anyway.

[orklah]

Yeah, recurrent issue. It should not be an issue if we start generating stubs as we talked

[AndrolGenhald]

I figure there should probably be an XML config to enable/disable extensions as well, but this seems to work fine so far.

[AndrolGenhald]

I was just thinking about require-dev. It would be nice if it were possible to load extensions in require-dev for specific namespaces such as tests, but as far as I'm aware there's no way to tell Psalm to only load a stub for use in a specific namespace. This might have to be part of a more general require-dev support, it would also be nice to exclude loading require-dev libraries when inspecting non-dev code.

[AndrolGenhald]

Tests all run fine locally with #7110 merged. I'll see to getting an XML config added and then I think it's good to go.

[orklah]

Seems like tests are failing. Maybe due to your last commit?

[AndrolGenhald]

Odd, they all run fine locally. Must be a PHP version issue.

Edit: Wait no, of course, it's because I re-enabled the SOAP extension locally after I got those tests to work the first time.

[AndrolGenhald]

I need to read before going and debugging again...
Those tests fail due to a separate bug fixed in #7110, when that's merged I'll rebase and everything should be fine.

[AndrolGenhald]

@orklah anything I can do to streamline review of some of these pull requests? I'm seeing several other pull requests that are going to cause conflicts.

[weirdan]

Ideally I'd like to merge CI fix and CS change before all other PRs.

[orklah]

@AndrolGenhald Thanks for your PRs, it's really great! I'm having a hard time reviewing everything though!

This one is relatively easy to review, but if you could take the habit of summarize your most complex PR to explain the reason behind the biggest changes and challenges you encountered, it would help a lot :)

[AndrolGenhald]

Feel free to liberally point out any areas that aren't explained well enough. In the future I'll try to do multiple commits when moving around and deduplicating code sections, I expect being able to see each step in the refactor would help a lot with reviewing.

[AndrolGenhald]

@orklah I believe this is ready to go, just blocked by #7110 (failing tests are due to the added stub not being handled correctly).

[AndrolGenhald]

Currently rebasing on master, I'll have to open a pull request against 4.x to add loadXdebugStub to the deprecated attributes list. Doesn't look like we're documenting those in UPGRADING.md?

[orklah]

No, we only documented config properties removal in UPGRADING

[AndrolGenhald]

@orklah I'm trying to update the baseline on 4.x, but every time I try it's just giving me an empty baseline and saying "No Errors" without actually performing a scan. Any idea what's going on there?

It looks like there are also some errors showing up on 4.x that aren't in the baseline, but it's being a bit inconsistent. Might be because I'm trying to modify it manually.

[AndrolGenhald]

@orklah is there any plan to version the documentation on psalm.dev? Maybe add psalm.dev/docs/v4 and psalm.dev/docs/v5 or something? Not sure if I should be removing deprecated stuff from the documentation or not.

[orklah]

No plan for that no. Changes will be little enough I think and we'll probably advise anyone complaning to update versions anyway...

[AndrolGenhald]

Should I add back in the documentation for loadXdebugStub then with a deprecation/removed note? I worry about people upgrading from an older version of 4 straight to 5, so they might never get the deprecation notice and see what they're supposed to do to fix it.

[orklah]

Thanks!

[AndrolGenhald]

@orklah

Should I add back in the documentation for loadXdebugStub then with a deprecation/removed note? I worry about people upgrading from an older version of 4 straight to 5, so they might never get the deprecation notice and see what they're supposed to do to fix it.

[orklah]

You can add a note in UPGRADING I guess, I'd just like to avoid keeping things in the xml with no uses

[AndrolGenhald]

You can add a note in UPGRADING I guess, I'd just like to avoid keeping things in the xml with no uses

Oh, sorry I wasn't clear enough, I meant the documentation at psalm.dev/docs. If we're not versioning that people will be using Psalm 5 docs for Psalm 4, so we should probably be careful to avoid removing documentation.

[orklah]

I'm fine with that :)

[weirdan]

If we're not versioning that people will be using Psalm 5 docs for Psalm 4, so we should probably be careful to avoid removing documentation.

Should the need arise we'll provide documentation for previous versions on readthedocs.org, so feel free to remove outdated parts from master.