Allow multiple unpackagedMetadata paths

[jclark-dot-org]

Is your feature request related to a problem? Please describe.

I have a DX project with multiple unlocked packages defined. Some packages have dependencies on other packages, and some can stand alone. This works fine for the package code itself, but can require workarounds for common test support classes, because I cannot share unpackagedMetadata between packages when packaging.

What are you trying to do

Here is a simplified sfdx-project.json with 2 packages that demonstrates:

{
  "packageDirectories": [
    {
      "path": "force-app",
      "default": true,
      "unpackagedMetadata": {
        "path": "unpackaged-test-metadata"
      },
      "package": "core-apex-utils",
      "versionName": "ver 1.4",
      "versionNumber": "1.4.0.NEXT"
    },
    {
      "path": "core-lwc-utils",
      "unpackagedMetadata": {
        "path": "core-lwc-utils-test-metadata"
      },
      "package": "core-lwc-utils",
      "dependencies": [
        {
          "package": "core-apex-utils",
          "versionNumber": "1.4.0.3"
        }
      ],
      "versionName": "ver 1.0",
      "versionNumber": "1.0.0.NEXT",
      "default": false,
    },
  "name": "core-utils",
  "namespace": "",
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "56.0",
}

The first package, core-apex-utils, contains Apex classes. Its unpackaged metadata in path unpackaged-test-metadata includes Test Object Factory classes that are useful for many test classes.

The second package, core-lwc-utils, contains LWCs, some of which use Apex controllers, which reside in the unpackaged directory core-lwc-utils-test-metadata. These classes can use the Test Object Factory classes from the first package when developing in the scratch org, but when we build a version, the dependency only installs the packaged core-apex-utils version, not its unpackaged metadata.

I considered having a single, shared unpackagedMetadata directory, however, the unpackaged metadata for core-lwc-utils includes a "test harness" LWC which hosts the other LWCs for UI testing. This cannot be installed in an org when packaging core-apex-utils, so I have to maintain two unpackaged directories.

Describe the solution you'd like

I'd like to be able to provide a list of paths in unpackagedMetadata. For example:

    {
      "path": "core-lwc-utils",
      "unpackagedMetadata": {
        "paths": ["core-lwc-utils-test-metadata", "unpackaged-test-metadata"]
      },
      "package": "core-lwc-utils",
      ...
    }

Describe alternatives you've considered

For now, the only workaround is to duplicate any unpackaged test code that is needed by multiple packages.

Additional context

These packages are currently unlocked, but we are considering moving them to (2nd gen) managed packages with global methods in the future. These packages contain common utilities and reusable components that we use with multiple clients.

[github-actions[bot]]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments.

[git2gus[bot]]

This issue has been linked to a new work item: W-12526269

[AllanOricil]

@jclark-dot-org while this isn't implemented, as a Workaround suggestion, you could create a script that bundles ur N unpackaged metadata directories before creating a package version. This script creates a temporary directory which is set on the sfdx-project.json (unpackagedMetadata.path) before creating a package version. Later, at the end of the version creation, delete this temporary directory. This way you can still version your multiple unpackaged metadata directories separately in the same repo.

I recommend u to use the OS's temporary directory in ur script so that it works smoothly when running on CI servers

...
"unpackagedMetadata": "~/tmp/bundle-for-build-x" },
...

This small automation isn't hard and you will be able to combine ur unpackaged metadata directories in multiple different ways.