Apex Language Server

The Apex Language Server library provides a collection of tools to aid development of Salesforce Apex projects. Check for errors, find types, suggest code completions and more.

Getting Started

Installation

Releases are available from SonaType. You will need to add the repository to your build tool.

Scala:

// Add if not present
ThisBuild / resolvers ++= Resolver.sonatypeOssRepos("releases")

project.settings(
  // Replace %% with %%% to use ScalaJS build
  libraryDependencies += "io.github.apex-dev-tools" %% "apex-ls" % "X.X.X"
)

Maven:

<!-- In <repositories/> -->
<repository>
  <id>oss.sonatype.org</id>
  <url>https://s01.oss.sonatype.org/content/repositories/releases</url>
  <releases>
    <enabled>true</enabled>
  </releases>
</repository>

<!-- In <dependencies/> -->
<dependency>
  <groupId>io.github.apex-dev-tools</groupId>
  <artifactId>apex-ls</artifactId>
  <version>X.X.X</version>
</dependency>

Usage

The library can be consumed in JVM and ScalaJS projects, however the features available to each differ. See the JavaDoc for more details on the API.

The jar is also executable without a client via the commands, CheckForIssues and DependencyReport:

# Assuming dep jars are in the same directory
java -cp "apex-ls*.jar" io.github.apexdevtools.apexls.<CommandName> [args]

The following arguments are available:

Argument	Description	Supported Commands
--format / -f	Output format: text (default) | json | pmd	All
--logging / -l	Text output logging level: none (default) | info | debug	All
--nocache / -n	Do not load from or write to an existing apex-ls cache.	All
--cache-dir / -c	Cache directory path, defaults to APEXLINK_CACHE_DIR env or $HOME/.apexlink_cache.	All
--workspace / -w	Workspace directory path, defaults to current directory. Must contain an sfdx-project.json file.	All
--detail / -d	Detail level: errors (default) | warnings | unused	CheckForIssues

Development

Building

The build is a cross project for JS and JVM; SBT commands are aggregated, but can also be executed separately with sbt apexlsJVM/[cmd] or sbt apexlsJS/[cmd].

Available build commands:

• sbt build - Creates packaged jar or js bundle for testing and release.
• sbt apexlsJS/Dev/build - Creates fast optimised js bundle for debugging.
• sbt pack / sbt "pack [version]" - Do a local published release of the most recent tag or given value.
  • WARNING: This can override the remote releases, clear your ~/.ivy2/local directory to revert.
• sbt test - Execute full test run.
• sbt clean - Removes most build files and artifacts.
• sbt scalafmtAll - Reformat code files using scalafmt

Testing

In addition to the regular automated tests, we system test against a number of sample projects collected in the apex-samples repository. Follow the README instructions in apex-samples to checkout the submodules. To run the tests:

# Set SAMPLES env var to samples repo location
export SAMPLES=<abs path to apex-samples>

# Exec test script
cd js/npm
npm run test-samples

System test failures relating to the snapshots may highlight regressions. Though if an error is expected or the samples have changed, instead use npm run test-snapshot to update the snapshots, then commit the changes.

The tag version of apex-samples used by builds is set in the build file.

Release

Releases are automated via workflow on publishing a release. Create a v prefixed tag at the same time on the commit to be released (e.g. v1.0.0).

Snapshot releases can also be created at any time by executing the Publish workflow on a branch. The versioning will be in the format X.X.X+Y-yyyy-SNAPSHOT; the latest tag followed by recent commit info.

Updating To New API Version

See doc page.

License

The source code forked from apex-link & pkgforce uses a 3-clause BSD licence. Additional contributions:

• The antlr4c3 CodeCompletionCore.java has been embedded under a MIT licence.