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 Composer for PHP #35

Open
mamchenkov opened this issue Oct 19, 2018 · 2 comments
Open

Support Composer for PHP #35

mamchenkov opened this issue Oct 19, 2018 · 2 comments

Comments

@mamchenkov
Copy link
Contributor

PHP is one of the most popular programming languages. It powers almost 80% of all websites.

There is a huge developer community and numerous libraries, frameworks, tools, etc. Adding even the most popular of these to the libs/php.json will take forever. And then maintaining the list will also require a huge effort.

I think there is a better and simpler way though. Most of the modern PHP projects use Composer dependency manager. Those that do, have composer.json file in the root of the repository. The structure of this file is very well known and documented.

composer.json usually provides all the necessary information about the project / repository, such as name, URL, type, license, class namespaces, dependencies, and so on. If support for Composer is added to Sourcerer, it will immediately expand the knowledge and understanding of the PHP repositories, without doing any manual work. And it'll be easier to keep things up-to-date too.

I think this can also be implemented as a more or less generic support for dependency management tools, as there are others (npm for Node.js, etc). Extracting this information from the project repositories is a lot easier, faster, and more reliable than maintaining the technology lists manually.

@asurkov
Copy link
Contributor

asurkov commented Oct 19, 2018

@mamchenkov I like the idea, however I'm not clear how composer packages will be mapped into sourcerer's techs. Do the composer has anything similar that we can use to make an educated guess about techs?

@mamchenkov
Copy link
Contributor Author

@asurkov ,

consider an example. I have recently sent this PR to add CakePHP framework to the PHP technologies. This is manual.

However, if CakePHP was part of my GitHub repositories, once I update my Sourcerer profile, Sourcerer would find the composer.json in the root folder and analyse it. Just from that file alone, the following can be established:

  • The repository is a PHP project (just because composer.json is present).
  • Project name and description.
  • Type (library, plugin, etc)
  • Homepage and other links (useful, additional to the repository URL itself)
  • License (which is not yet used/analysed by Sourcerer, but would be cool)
  • Class namespace (in autoload.psr-4 section).
  • Relationship with other projects (this might come in handy later)

There is sufficient information to avoid the need for the manual PR that I sent in. Also, if the project developers update, for example, the tags later, it'll be easy for the Sourcerer to keep information up-to-date without the manual intervention.

Here's an another example: composer.json from the DebugKit plugin for the CakePHP. The type indicates the "cakephp-plugin" and the requirements point to "cakephp/cakephp" as well, making it somewhat easy to identify that whoever works on this repository is actually working with the CakePHP as a technology.

I think this provides additional value for the Sourcerer profiles for those developers who work on all kinds of extensions, plugins, etc. on top of some system/framework. Having a badge of "Top WordPress Contributor" is very nice. Getting it for building WordPress plugins and themes, and not actually working on the core of the WordPress is even better.

Have a look at the list of supported package types in composer. Getting just the type alone from the composer.json helps identify a large chunk of all PHP technologies.

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

2 participants