Feature request: A simple set of rules for all modules to follow.

[websafe]

Of course a rule set in context of a repository of ZF modules, a set of rules that helps developers to find and identify Zend Framework modules, even if they're not in this (or any other) repository.

Maybe a good starting point would be simple requirement of "type": "zf-module" in the composer.json of ZF modules?

I really don't want to force developers to do crazy things, or create additional files, I'm just looking for a more universal way of finding/identifying Zend Framework 2 modules. My first thought was composer.json because the modular system is already utilizing Composer. We could expand this set of "types": zf-module, zf-app, zf-lib, zf-translation.

---

http://getcomposer.org/doc/04-schema.md#type

type

The type of the package. It defaults to library.

Package types are used for custom installation logic. If you have a package that needs some special logic, you can define a custom type. This could be a symfony-bundle, a wordpress-plugin or a typo3-module. These types will all be specific to certain projects, and they will need to provide an installer capable of installing packages of that type.

Out of the box, composer supports three types:

• library: This is the default. It will simply copy the files to vendor.
• project: This denotes a project rather than a library. For example application shells like the Symfony standard edition, CMSs like the SilverStripe installer or full fledged applications distributed as packages. This can for example be used by IDEs to provide listings of projects to initialize when creating a new workspace.
• metapackage: An empty package that contains requirements and will trigger their installation, but contains no files and will not write anything to the filesystem. As such, it does not require a dist or source key to be installable.
• composer-plugin: A package of type composer-plugin may provide an installer for other packages that have a custom type. Read more in the dedicated article.

Only use a custom type if you need custom logic during installation. It is recommended to omit this field and have it just default to library.

---

But I'm not sure if type will be the best place? Another possible option would be a tag in keywords. I think it's much safer/transparent.

---

http://getcomposer.org/doc/04-schema.md#keywords

keywords

An array of keywords that the package is related to. These can be used for searching and filtering.

Examples:

logging
events
database
redis
templating

---

ZF modules rules

1. A composed.json file is required.
2. Create a module and don't forget to add the keyword zf-module in the keyword section of composer.json. This is not a requirement, but will help other developers/repos/apps to identify Your package as a ZF module and Your module will probably reach more users ;-)

That's just an idea.

Update

We can probably try to identify zf-modules among other libraries (listed in require/suggest) by checking
if the value of autoload => classmap contains Module.php or src/Module.php. Or a combination of this check and an additional check for a specific keyword?

    "autoload": {
        "psr-0": {
            /* ... */
        },
        "classmap": [
            "./Module.php"
        ]
    },