Skip to main content

The .elp.toml Configuration File

A .elp.toml configuration file can be added to a project's root directory to customize the behaviour of ELP for a given project.

The file can also be used as an absolute marker for the root of an ELP project, If one is found - and it contains all the required information -, ELP will not perform any upward auto-discovery for the structure of a project.

A Sample .elp.toml Configuration File​

Here is an example of a full .elp.toml file. All sections are optional. The build_info can be used to mark the root of a project (via the build_info property). The available configuration sections are described below.

[build_info]
file = "my_hand_crafted_build_info.json"

[eqwalizer]
enable_all = true
max_tasks = 32
ignore_modules = ["very_big_generated_module"]

[buck]
enabled = false

[rebar]
profile = "test"

[otp]
exclude_apps = ["megaco", "eunit"]

[daemon]
idle_timeout_secs = 3600
startup_timeout_secs = 240

Configuration Sections​

[build_info]​

This section is used to configure project discovery.

KeyTypeDescription
fileStringPath to a JSON file describing the project. This is only honoured if buck.enabled is false or missing. The format of the JSON file is described in the build_info.json section.
appsString or Array of Strings/App DataA string pattern or a sequence of string patterns or app data used to generate the applications for the build_info.json configuration. Unused if file is specified. See below for examples.
depsString or Array of Strings/App DataA string pattern or a sequence of string patterns or app data used to generate the dependencies for the build_info.json configuration. Unused if file is specified. See below for examples.

The apps and deps fields can contain a string pattern or a sequence of string patterns. Each pattern can use wildcards. E.g.

[build_info]
apps = ["some_apps/*", "more_apps/*"]
deps = "deps/*"

Each pattern will be expanded, behind the scenes, to an app, as described in the build_info.json section. Each app will look something like:

{
"name": "app_name",
"dir": "path/to/app", // Relative to project root
"src_dirs": ["path/to/src", ...], // Relative to app dir, defaults to ["src"]
"extra_src_dirs": ["path/to/extra_src", ...], // Relative to app dir, defaults to []
"ebin": "path/to/ebin", // Relative to app dir, defaults to "ebin"
"include_dirs": ["include", ...], // Relative to app dir, defaults to []
"macros": ["MACRO", ...], // Defaults to []
}

It is possible to override these values for a given app. For example:

[build_info]
apps = [ "some_apps/*",
"more_apps/*",
{name = "special_app", dir = "some_apps/special_app", "src_dirs" = ["src", "more_src"]}
]
deps = "deps/*"

The order in which the entries are specified is important, in the sense that "the last entry wins". In the above example, the special_app in some_apps/special_app will contain an extra source directory, while all the other apps in the same some_apps directory will default to src only.

[eqwalizer]​

ELP is integrated with the eqWAlizer type checker. The integration can be configured via this section.

info

By default eqWAlizer is enabled on all non-test modules, including generated modules. This can be overriden per module via the following attributes:

  • -eqwalizer(ignore). Opt-out module unconditionally
  • -typing([eqwalizer]). Opt-in unconditionally, even for test modules
KeyTypeDescription
enable_allBooleanEnable eqwalizer for all modules by default, but still honours the module-specific overrides listed above and the ignore_modules list.
max_tasksIntegerMax number of parallel eqWAlizer tasks, defaults to 4 (eqWAlizer instances are memory intensive). This only applies to using eqWAlizer from the CLI.
ignore_modulesList of StringDisable eqwalizer for individual modules from the config.

[buck]​

Configure the interaction between ELP and the Buck2 build tool. See this presentation for details about Erlang support for Buck2.

KeyTypeDescriptionDefault
enabledBooleanDiscover the project using Buck2
test_application_labelsArray of StringsBuck2 labels that identify test application targets. Targets with any of these labels will be treated as test utilities.["test_application"]

The test_application_labels setting allows you to customize which Buck2 labels indicate test applications. This is useful for:

Example usage:

[buck]
enabled = true
test_application_labels = ["test_application", "integration_test", "e2e_test"]
warning

The github version is not built with buck2 support enabled. This will change soon, once we tweak the tests.

[rebar]​

Configure ELP for rebar3-based projects.

KeyTypeDescriptionDefault
profileStringThe rebar3 profile to use for project discovery. Only used if the file property is specified in the build_info section.test

[otp]​

Configure ELP's interaction with OTP (Open Telecom Platform) applications.

KeyTypeDescriptionDefault
exclude_appsArray of StringsList of OTP application names to exclude from indexing. This can help improve performance by not loading rarely used OTP apps.[]

The exclude_apps setting allows you to specify OTP applications that should not be indexed by ELP. This can be useful for:

  • Improving performance by excluding rarely used OTP applications like megaco
  • Reducing memory usage when working on projects that don't need certain OTP libraries

Example usage:

[otp]
exclude_apps = ["diameter", "megaco"]

[daemon]​

Configure the ELP daemon lifecycle.

The daemon relies on watchman, so commands use it by default only when watchman is on PATH. If the daemon cannot start, commands report why and run without it. Pass --no-connect to skip the daemon, or --connect to require it.

KeyTypeDescriptionDefault
idle_timeout_secsIntegerSeconds of inactivity before the daemon shuts itself down. Set to 0 to keep the daemon running indefinitely.3600
startup_timeout_secsIntegerSeconds a client waits for a freshly spawned daemon to accept connections before giving up. Set to 0 to wait indefinitely for startup.120