Allow changing vendor path for package output

[mike-potter]

I implemented the approach suggested by arithmetic. Comments welcome.

[mike-potter]

Referenced from this issue: #288

[mike-potter]

This still needs additional work though. It covers the build paths in the composer.json but it doesn't cover the case of moving the vendor directory and updating the autoload.php.

[mike-potter]

Yeah, needs a lot more work. When testing, the composer.json that ended up in the package was still the original. The current PR modifies the composer.json in the root instead of the one being packaged.

[mike-potter]

OK, updated this PR. Added a new Gruntconfig.json option:

packages : dest : "vendor"

You can set this to the desired location of the /vendor directory. If left out or empty the composer.json will be saved to the normal buildPaths.html. If "vendor" is used, it is a relative path to the buildPaths.html that specifies where to place the composer.json file.

The installer-paths in the composer.json are updated based on the settings of both the packages.dest.docroot as well as packages.dest.vendor. When the vendor is set, the installer-paths need to be made relative to the location of composer.

So, a simple test case:

"docroot": "docroot",
"vendor": "docroot"

This will put the composer.json within packages/package/docroot which is where the vendor directory will get created, and the installer-paths generate from that same directory. This would be the typical setup for Acquia.

Another contrived example:

"docroot": "build/html",
"vendor": "build"

This puts composer.json into the packages/package/build folder, but sets the installer-paths to "html/*". This would let the web server point to /build/html but have the vendor directory in /build which might still be within the hosting file structure.

[arithmetric]

@mike-potter Thanks for taking this up!

The test cases you listed are good ones, but I'd simplify them slightly:

1. Everything ends up in build/packages/package (all output from build/html, the vendor directory, and the composer files). This is most like the default packaging output from previous versions of Grunt Drupal Tasks. I would expect to get this output by leaving packages.dest undefined/empty in Gruntconfig.json or setting it explicitly to:

"packages": {
  "dest": {
    "docroot": "",
    "vendor": ""
  }
}

1. The likely best approach is to have the vendor directory live in the same directory as the docroot directory (one level up from index.php). In this case, the build/packages/package directory would include the docroot in html, the vendor directory, and the composer files. I would expect to get this output with the following configuration:

"packages": {
  "dest": {
    "docroot": "html"
  }
}

When testing these two configurations, I found a few issues:

• The updated code treats config.packages.dest.docroot as a required setting, where it used to be optional and only needed when changing from the default of build/packages/package. Currently if you do not define config.packages.dest.docroot, the composer.json install-paths are updated with an undefined/ path prefix.
• This solution does not update the path in the autoload.php in the docroot (which is created by the drupal-scaffold package during build). One way I found to update this path is to run the Composer drupal-scaffold script in the package directory after other changes. However this script also triggers the full scaffold step, including downloading core and other components. Ideally we would only run the generateAutoload routine: https://github.com/drupal-composer/drupal-scaffold/blob/master/src/Handler.php#L133

I'll submit a PR against this branch with updates that I'm testing to resolve these issues.

[mike-potter]

There we go...travis is passing now. Seems to be a bit flaky these days and just re-running the builds worked. Adam is out for 3 weeks so I'm going to ping Jonathan for a review/test and then we can commit this. I'll be working on some docs but hope we can do the 1.0 milestone very soon.

[jhedstrom]

This looks good to me. @arithmetric any further feedback here?

[arithmetric]

I think this is ready to go. I'll push out another alpha release with this.

Let's make sure documentation is up-to-date (address #271) and aim to release 1.0.0 in the next couple weeks.

[mike-potter]

I'm going to work on the documentation today and later this week. I really want to push the 1.0.0 release asap because we have D8 projects that need the composer support and the current projects using gdt "^0.11.0" are not seeing any of these "alpha" releases, even though there is nothing in them that would break existing drush-make-based projects.