-
Notifications
You must be signed in to change notification settings - Fork 2
ApexAssist Project Setup
The code analysis in ApexAssist is provided by the apex-link library. These instructions are really about how to setup apex-link, any tool based on this library will operate the same way. If you are interested in how metadata is managed internally within ApexAssist see Understanding Metadata Layering
The ApexAssist extension only activates in workspaces which have a sfdx-project.json file at the root of the workspace. However, in current versions it will happily read both the older MDAPI format metadata and the newer SFDX format metadata files. If you have an older project that can't yet be converted to SFDX format, creating a simple sfdx-project.json file for it will allow you to use ApexAssist.
The semantic analysis done by ApexAssist requires access to various types of metadata to ensure that the Apex code in classes and triggers is valid. To do this it needs access to:
- Custom Labels
- Custom Objects & Fields, incl. custom settings, platform events, custom metadata and big objects
- Visualforce pages & components
- Flows
Definitions for Standard Objects and Platform APIs are built into the tooling.
For Apex code that only references these types of metadata from within the same project then there is no need for additional setup. However, projects that reference metadata that is not provided in the current project will usually require some additional setup steps which are discussed below.
If your project does not contain all the metadata referenced from Apex classes and triggers then you will likely see a lot of error messages relating to these metadata items. There are two ways to fix this. The preferred approach is to import definitions for the missing metadata from an org where you have it available. In the second approach you can declare that the metadata is not available for analysis, this is discussed in the next section.
The simplest way to import is to use the 'Assist: Download metadata from org' from the VSCode command palette:
When this command is run it will prompt you to pick the namespaces for the metadata to download, download the metadata to a '.apexlink' directory in your workspace and update sfdx-project.json to indicate the metadata is available.
There is screen recording of this on YouTube.
This download process replaces any previously downloaded metadata each time it is run so is not as useful where you need to import many namespaces. As an alternative you can use the apex-link sfdx plugin to download/update metadata incrementally. It is likely that a future release will contain an improved download model for supporting working with larger numbers of packages.
As explained in Understanding Metadata Layering ApexAssist manages metadata in layers that must be arranged in a deployable order. The ordering used is described in a 'additionalNamespaces' section of your sfdx-project.json file:
{
"packageDirectories": [
{
"path": "force-app",
"default": true
}
],
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "52.0",
"plugins": {
"additionalNamespaces": ["ns1", "ns2"]
}
}
In this example, metadata from ns1 is layered beneath metadata for ns2. This means ns2 metadata can reference ns1, but ns1 can not reference metadata for ns2. For each entry the metadata is assumed to be stored in your workspace .apexlink/gulp/<namespace> directory.
As an alternative to importing you can also specify the metadata for specific namespaces is unavailable. Doing this will suppress errors from the namespaces provided. This approach is not recommended as it can hide problems for you. In a future version we intend to deprecate this feature.
{
"packageDirectories": [
{
"path": "force-app",
"default": true
}
],
"sfdcLoginUrl": "https://login.salesforce.com",
"sourceApiVersion": "52.0",
"plugins": {
"dependencies": [
{
"namespace": "ns1"
}
]
}
}
In this example, any references found to the namespace ns1 are assumed to be valid and so no errors will be generated for those references. Of ApexAssist has no way to check if they are valid or not, you will only find out if they are when you try and deploy your apex code.