Revise grunt package to be multi-target, cleaner configuration schema

[grayside]

grunt package is versatile, but is fundamentally limited to one type of packaging per project. Furthermore, it's configuration is confusing and it is currently limited to copy operations to move files around, which is providing slow or incapable in some cases.

Let's rebuild tasks/package.js. It might help to start with the most current documentation.

Action Items

1. Revise package to be a multi-target grunt task. Per grunt conventions each target should have it's own configuration, though a top-level "options" config item should be able to provide global defaults.
2. Move :compress target to --compress as a flag. It's also noted as a configuration option.
3. Use rsync when possible and fall back to copy for Windows, as we do in the tasks/make.js for the drushmake task.
4. Convert the config schema to something like what's proposed below.
5. Consider extracting the core package functionality to a separate project. This might be sufficiently involved that it should be a dedicated grunt plugin.

Multi-target, Multi-use Configuration Schema

Proposed configuration schema

The schema below demonstrates a new configuration concept exercised with a number of different targets which map to different use cases:

• default package
• archival package
• acquia package
• docker package (e.g., run inside a docker container)

{
  package: {
    options: {
       src: {
         docroot: {
           include: [ "build/html" ],
           exclude: [ "build/html/xmlrpc.php", "build/html/modules/php" ],
         },
         root: {
           include: [ "*.md" ],
           exclude: [],
         }
       },
       dest: {
         docroot: "",
         root: ""
       },
       compressed: false
    },
    default: {
       "name": "override-target-name"
    },
    archive: {
       compressed: true
    },
    acquia: {
      src: {
        root: {
          include: [ "hooks", "bin" ],
        }
      }
      dest: {
        docroot: "docroot"
      }
    },
    docker: {
      dest: {
        docroot: "/root/var/www",
        root: "/root/var/docs",
      }
    }
  }
}

Implicit Defaults

We want to make sure grunt package still does something meaningful out of the box, so here is something that approximates the current behavior out of the broader configuration options explored above:

{
  package: {
    options: {
       src: {
         docroot: {
           include: [ "<%= config.buildPaths.html %>" ],
           exclude: [ "<%= config.buildPaths.html %>/xmlrpc.php", "<%= config.buildPaths.html %>/modules/php" ],
         },
         root: {
           include: [ "*.md" ],
         }
       },
       dest: {
         docroot: "",
         root: ""
       }
    },
    default: {
      name: "package"
    },
  }
}

Configuring File Masks

As noted above, a lot of the configuration are file masks intended to indicate copying around sets of files. These should match typical Bash globbing behaviors rather than typical Grunt file matching, based on the more flexible and powerful minimatch library. This is to support the use of rsync as the engine of copying, and avoid the overhead of minimatch expansion on large numbers of files. This was previously discussed in #252.

The "namespaces" under the options.src (e.g., root and docroot) have no special meaning, and merely provide "subtargets" for a given package job. That means we may want configuration able to ad hoc define additional namespaces like that in the future. Since that has a certain amount of overhead, it might be worth nixing the namespace concept for implementation and instead putting together more typical src => dest configuration objects, which can happen to match copying docroot.

If the "options" parameter has values and a target does as well, the values should be merged together into a larger array.

package can be run as grunt package:default for a specific target, or grunt package:default:root for a specific namespace. Note that combined with the compress flag this either discards other namespaces or we would need to update files within the archive which sounds potentially messy for cross-compatibility. Each namespace would be a separate rsync or copy operation.