Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Use a more precise autoload prefix #1078

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

stof
Copy link
Contributor

@stof stof commented Sep 24, 2024

As phpdocumentor/guides-markdown provides only classes for the Markdown subnamespace, using a more precise autoload prefix for the PSR-4 configuration will allow the ClassLoader to avoid checking that package for other guides classes.
This won't make much difference when using an optimized autoloader with level 2 optimizations as the classmap will be used instead of checking the filesystem. But it will help a bit when using a non-optimized autoloader (which is common in dev environments as that provide a better DX when your codebase gets edited).

If this is considered good by maintainers, I will update the PR to apply that to other packages rather than just guides-markdown as others could also benefit from it.
Also, maintainers should decide whether they prefer using src/Markdown/ as path in the config or flattening the src folder by removing the Markdown folder entirely (similar to what is done for guides-cli). Both options are valid and I'll happily apply the preferred one when updating this PR to cover all packages.

@jaapio
Copy link
Member

jaapio commented Sep 25, 2024

Thanks for reaching out to us, I think it would be nice to have this optimization in the composer.json files of the projects. A PR for those changes would be very nice.

Regarding the folder structure, I think we prefer the flattest structure, we must have missed that when we were splitting the project into separate packages. However changing this could have the downside of a harder to track history. I'm not sure if we should do that? @linawolf what do you think?

@linawolf
Copy link
Contributor

I think if we are moving the files in their own commit without changing them further in that commit git should be able to realize they were moved and not deleted and then created a new

@jaapio
Copy link
Member

jaapio commented Sep 26, 2024

Ok, let's go for it @stof

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

Successfully merging this pull request may close these issues.

3 participants