Skip to content

BC break from 4.1.2 if you have badly named entity? #7067

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wtfred opened this issue Apr 7, 2025 · 3 comments
Closed

BC break from 4.1.2 if you have badly named entity? #7067

wtfred opened this issue Apr 7, 2025 · 3 comments
Labels

Comments

@wtfred
Copy link

wtfred commented Apr 7, 2025

API Platform version(s) affected: 4.1.2 and more

Description
I upgraded this morning from api-platform/core 4.0.16 to api-platform/core 4.1.6, and i got 2 routes "disappeared"
Routes where from 2 differents entities, Test.php and OneOffTest.php
I found the commit causing this was this one ba57714#diff-0d56a84d21cd4b276d12f866fb873f975a4ceb373ad27b902802f23c8f32fb76 introduced in api-platform/core v4.1.2

So yeah, i know my naming is not the best, but after all, it is for an API managing tests from students.

Is there some strict naming convention in PHP, Symfony or Api platform preventing me for having an entity named FooTest.php?

Should i rename my entities, or does this regex needs to be a bit more permissive?

Thanks

@soyuka soyuka added the bug label Apr 8, 2025
soyuka added a commit to soyuka/core that referenced this issue Apr 10, 2025
@soyuka
Copy link
Member

soyuka commented Apr 10, 2025

does my patch resolves your issue? ddc2734

@wtfred
Copy link
Author

wtfred commented Apr 10, 2025

Yes, thanks!

(That being said, problem could still happens on Laravel with entities named like mine, no?)

@soyuka
Copy link
Member

soyuka commented Apr 11, 2025

Actually if I don't do this there are some issues as we will load pest tests and break cache warmup. Autoconfiguring in laravel is quite experimental to me. I also hope that I can find some energy to resolve #6943, when ApiResource attributes will be handled by symfony's DI component we can remove this code for the symfony integration it'll be much cleaner :)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants