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

Support for PHP source directory #175

Open
phpfui opened this issue May 29, 2020 · 7 comments
Open

Support for PHP source directory #175

phpfui opened this issue May 29, 2020 · 7 comments

Comments

@phpfui
Copy link

phpfui commented May 29, 2020

Carsten,

This is a great package. Been using it for a while on my PHPFUI site which easily documents any PHP code.

I was wondering if you would be up for a Pull Request to put the PHP source in it's own directory. This is pretty standard practice for PHP libraries. I would be willing to submit one, I just don't want to do the work if you have a reason to keep it the way it is. I would go with either PSR-4 or PSR-0 autoloading depending on if you have a preference.

This should not affect any user of the package if they are using composer to install it. The reason I am interested in a dedicated source directly is my PHPFUI site does not use composer for deployment, but has everything checked in. I have a script that copies over files, but it can't easily distinguish between test code and package code. It is also a good logical separation in general.

Anyway, let me know if you think this would be a good idea. Happy to contribute to this excellent project.

Bruce

@samdark
Copy link
Contributor

samdark commented May 31, 2020

put the PHP source in it's own directory

You mean src?

I would go with either PSR-4 or PSR-0

It is already PSR-4: https://github.com/cebe/markdown/blob/master/composer.json#L30

@phpfui
Copy link
Author

phpfui commented May 31, 2020 via email

@samdark
Copy link
Contributor

samdark commented May 31, 2020

That's for @cebe to decide but I support this move.

@phpfui
Copy link
Author

phpfui commented May 31, 2020 via email

@cebe
Copy link
Owner

cebe commented Jun 2, 2020

what are the arguments for doing this? I only see one argument, that your tool is unable to distinguish files?

@phpfui
Copy link
Author

phpfui commented Jun 3, 2020

I think the primary reason is just to separate things so they are better defined for users and tools. Most PHP packages use an src directory, but it could be named source or something else. The point is to tell the user this is all that is really needed for this package to work. You can also point a tool at it one source directory, and it will have everything it needs to know about. Right now, you have to specifically exclude the test directory to just get the actual PHP source code the package uses.

Basically, you are almost there. Create a src directory. It would contain the and 4 php files in the root, plus the block and inline directories. Then a user could glance at the project and see block and inline are part of the package namespace. While bin and tests are obviously not part of the package, you really can't be sure unless you look at them specifically.

One example of why you might want this is if you were to grep the source for something, you might find matches in the test directory as well as the source, when you don't care about the tests. If you wanted to include the tests in the search, you simply start one level up. But searching just the source would then be easier.

In the end, what you have works. It is just not a typical PHP library layout. It keeps things a bit better organized in the end. Kind of the same reason we use namespaces, they keep things more organized.

Anyway, happy to submit a PR. I think it would be a good thing and make this package like most of the rest of the PHP community packages.

@samwilson
Copy link

Relatedly, there's some good info at php-pds/skeleton about common directory structures for PHP projects. They recommend src/ and tests/ among other things.

I guess it mostly comes down to standardization, and making it slightly quicker for people new to a project to know where things are.

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

No branches or pull requests

4 participants