Metadata Layering

The ApexAssist analysis organises metadata into a series of layers where each layer adds to the metadata of the layer below. The top-most layer is always for non-namespaced metadata, be that unmanaged metadata or metadata from an unlocked package that does not use a namespace. The bottom most layer contains the platform standard objects and access to platform namespaces such as System or Schema. In the middle you may have namespaced data from managed or unlocked packages.

For example, a stack of layers may look like:

├─Unmanaged
│  └─packageDirectoryA  
├─namespace1
│  ├─packageDirectoryB
│  └─packageDirectoryC
├─namespace2
│  └─packageDirectoryD
└─Platform

Here there are four directories that contain metadata, split between 2 namespaces and the "unmanaged" layer. Metadata in packageDirectoryA may reference metadata from package directories B, C & D. However, metadata from packageDirectoryC may only reference metadata from package directory D.

This layering is designed to allow ApexAssist to support base & extension package analysis as well as having multiple 2GP packages contributing to the same namespace. Note that the model here is subtly different from how an org works in that orgs allow cross layer referencing by default, you are only constrained by deploy ordering. Another way of thinking about this is that the metadata layering that ApexAssist uses actually defines a deployment order from bottom to top.

Where metadata is extensible, such as adding a custom field to a standard object there is some additional handling, in short an extended standard object is cloned into the layer which extends it. This cloned definition in effect overrides the default definition of the standard object for the layer that extends it and all layers above it.