axelerant / druposer-helper Goto Github PK

This can produce a more accurate site build and can solve issue #5. However, this is not ideal as the composer.json would then be a build script rather than a dependency file. All modules would be listed there even if we are not using them directly.

Ideally, we must only require modules we directly use and let it require its own dependencies. This works great in PHP world but not in Drupal once we start listing custom modules which may not be in their own repositories. See issue #5 for more details on the problem.

Right now, the script just outputs a composer file. We should add support to read a composer file, modify it depending on the projects in make file and output the updated composer.json.

The script carries forward sandbox modules from make file but it does not work. The Drupal packagist does not index sandbox modules and composer fails. Also, the version is incorrect (that could be a separate issue if required).

Something like this could be done for sandbox modules in repositories property:

    {
      "type": "package",
      "package": {
        "name": "drupal/user_track", // This has to be used in the `require`, which the script does.
        "version": "7.0.1",
        "source": {
          "url": "{url}",
          "type": "git",
          "reference": "7.x-1.x" // The branch
        }
      }
    }

There are certain scenarios when a info file may not directly point to all dependencies as a make file would. If the info file depends on custom modules which then depend on contrib modules, those contrib modules might not turn up in the build at all. This happens because the custom modules won't be present in the make file which means they would be skipped from composer.json and their dependencies would never be included.

Ideal way to fix this in composer world would be to have each custom module as a dependency. This is not really practical in a typical Drupal development where there may be tens of custom modules (feature modules).

These are our options:

• Each custom module as a dependency - This requires new repositories to point to each custom module or our own Packagist / Toran Proxy.
• The script reads each info file under a specific path (e.g. custom modules path) and process their dependencies as well. This would follow the same rules as parsing the main info file.
• Use composer-merge-plugin to merge down all dependencies from the custom modules. This means that any custom modules which have contrib dependencies should also include a composer.json file. This is not easy but certainly doable.

Right now, we can only read a YAML make file. There is some code to detect the format but there is only one parser - YAML. We need to add another parser and test the format detection code.

The version constraint for a dev release gets written as ~7.1.0@dev. This is incorrect because it only sets that stability flag, not the release required. See this link for examples.

If a release is marked as dev in the make file, it means we actually want the dev release and the above constraint does not pick that up. We need to use -dev instead of @dev to actually pick the dev release. The reason @dev does not work as intended is because prefer-stable needs to be true to pick up intended releases for other modules.

To correctly pick a dev release, the vesion constraint must be 7.1.*-dev.