PHPackages                             poposki/modcom - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. poposki/modcom

ActiveLibrary[Utility & Helpers](/categories/utility)

poposki/modcom
==============

Converter for a modman to a composer-ready project

0.1.0(10y ago)723MITPHPPHP >=5.5.16

Since Jun 12Pushed 10y ago3 watchersCompare

[ Source](https://github.com/dpoposki/modcom)[ Packagist](https://packagist.org/packages/poposki/modcom)[ Docs](https://github.com/dpoposki)[ RSS](/packages/poposki-modcom/feed)WikiDiscussions master Synced today

READMEChangelogDependencies (5)Versions (2)Used By (0)

ModCom - Modman to Composer converter
=====================================

[](#modcom---modman-to-composer-converter)

Dev share talk on how to convert a modman project to a composer ready one. This does not represent a production ready code (well.. you can still use it on your projects, but this just means that I provide no guarantee for the use).

The purpose of the talk was to show a quick way of converting a modman project (in the given case a Magento project) to a composer ready project. Basically in most of the cases you should be able to run the convert command and then `composer install`. Of course, after the convert you will need to clean up your composer file and make it better (read below) if you want to go live with it, but the point is that you can immediately run `composer install` after the conversion is done.

Installation
------------

[](#installation)

```
composer require poposki/modcom "~0.1"

```

Configuration
-------------

[](#configuration)

In order to prepare the project for converting you need a small configuration file which you can copy from `app/config/config.yml`. This is the default configuration file of the tool, but your project specific one should go under the project root you want to convert and should be named `modcom.yml`. Most of the config settings are self-explanatory, but I have explained some of them below. Whatever you don't need in the config you can remove.

```
# Project specific config
project:
    source_dir: 'src'
    vendor: 'Vendor'
    name: 'vendor/project'
    description: 'Here goes some fancy description'
    homepage: 'http://www.example.com'
    license: ''
    packages:
        php: '>=5.5'
        magento-hackathon/magento-composer-installer: '~3.0'
    repositories:
        "https://packages.firegento.com": 'composer'

# Local module specific config
module:
    homepage: 'http://www.example.com'
    license: ''
    packages:
        php: '>=5.5'
    repositories: []

# Modman config
modman:
    dir: ''
    dir_separator: '_'

```

Project specific config

- the project `source_dir` is the directory where the converted packages will be placed at the end
- the `vendor` is a fallback in case your directories under modman don't have vendor defined in their names. E.g., if your module is `ModuleName` instead of `Vendor_ModuleName`, then the `vendor` setting will be used when deciding where to place the package and which name to assign in the composer file
- under `packages` you can define any default packages that your project should end up with (same goes for `repositories`)

Module specific config

- these ones are basically the same as the project settings with the difference that these will be applied on the converted modules' composer files

Modman config

- the `dir` is where the modman modules are to be found
- the `dir_separator` (if any) is the one that separates the vendor from the module name (check the example) for the project `vendor` setting

Usage
-----

[](#usage)

There is only one command to run

```
modcom convert

```

Git submodules
--------------

[](#git-submodules)

If the project has git submodules (with the .gitmodule file found in the root of the project) then the tool will read from it and it will add as a repository to the composer.json file any package found in the system which is already composer ready.

This will help you with any private repository you have in the project and is composer ready, or with any 3rd party package which is not added to any of the official repositories.

On the other hand it might be the case that these packages are already on packagist, packages.firegento or on any other repository, but in this moment the tool doesn't check for that, so if that is the case the suggestion is to manually remove the repository urls from the composer file.

Composer package
----------------

[](#composer-package)

Any module found under the specified modman directory that is composer ready will not be moved to the source directory, but it will be just added as a package to the composer file. At this moment the tool is not checking for the checked out commit (if it is a submodule), and it doesn't run any checks on the public repos for tags which means it will be added with a `*` as a version. This is very project specific, so the dev will need to go in the composer file afterwards and set the wanted versions for each of the external packages.

Local package
-------------

[](#local-package)

The local modman modules will now be transferred to local composer packages with a `*@dev` added as a package version. All of them will be moved under the source directory under their own vendor namespaces, with each package having its own composer file. Also the corresponding local paths will be added to the composer file.

Folder structure
----------------

[](#folder-structure)

This is the suggested folder structure that you will end up with:

```
root
  ├── src
  | ├── vendor1
  | | ├── module1
  | └── vendor2
  ├── vendor
  └── composer.json

```

Ideally the magento source should go as a dependency in the composer file and then together with the project specific source found under the `src` directory will be deployed under the `htdocs` (or `web`or anything) directory. The example for the dev share was using the [magento hackathon composer installer](https://github.com/Cotya/magento-composer-installer), which will deploy all of the packages under the Magento installation.

Other use cases
---------------

[](#other-use-cases)

Although the converter initially called modman to composer, as a matter of fact it doesn't do anything modman specific. This means that you can apply this converter to any other project that has a similar structure.

License
-------

[](#license)

ModCom is licensed under the MIT License - see the LICENSE file for details

###  Health Score

24

—

LowBetter than 31% of packages

Maintenance20

Infrequent updates — may be unmaintained

Popularity12

Limited adoption so far

Community8

Small or concentrated contributor base

Maturity48

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Unknown

Total

1

Last Release

3670d ago

### Community

Maintainers

![](https://avatars.githubusercontent.com/u/10155725?v=4)[Darko Poposki](/maintainers/dpoposki)[@dpoposki](https://github.com/dpoposki)

---

Top Contributors

[![dpoposki](https://avatars.githubusercontent.com/u/10155725?v=4)](https://github.com/dpoposki "dpoposki (1 commits)")

### Embed Badge

![Health badge](/badges/poposki-modcom/health.svg)

```
[![Health](https://phpackages.com/badges/poposki-modcom/health.svg)](https://phpackages.com/packages/poposki-modcom)
```

###  Alternatives

[sulu/sulu

Core framework that implements the functionality of the Sulu content management system

1.3k1.4M196](/packages/sulu-sulu)[friendsoftypo3/content-blocks

TYPO3 CMS Content Blocks - Content Types API | Define reusable components via YAML

101466.4k45](/packages/friendsoftypo3-content-blocks)[shopware/core

Shopware platform is the core for all Shopware ecommerce products.

585.4M526](/packages/shopware-core)[open-dxp/opendxp

Content & Product Management Framework (CMS/PIM)

9417.2k58](/packages/open-dxp-opendxp)[chameleon-system/chameleon-base

The Chameleon System core.

1027.9k4](/packages/chameleon-system-chameleon-base)[2lenet/crudit-bundle

The easy like Crud'it Bundle.

1615.6k12](/packages/2lenet-crudit-bundle)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)