Gleam 1.0 target compatibility for erlang and javascript standard library modules

To maintain a codebase that targets both the BEAM and JavaScript, the recommended pattern is the interface-based abstraction. Because Gleam prevents compilation when modules like gleam/erlang/process or gleam/javascript are imported in the wrong target, you cannot use them directly in shared logic.

The Abstraction Strategy

Instead of attempting to use conditional imports within a single file, you should define a common interface in a neutral module and provide target-specific implementations:

1. Define the Interface: Create a target-agnostic module (e.g., my_app/process.interface) that defines the functions you need.
2. Create Erlang Implementation: Create a module (e.g., my_app/process/erlang_impl) that imports gleam/erlang/process and implements the interface.
3. Create JS Implementation: Create a module (e.g., my_app/process/js_impl) that imports gleam/javascript and implements the interface.
4. Export via Build: Use your project's directory structure or separate entry points to expose the correct implementation based on the compilation target.

Example Project Structure

A common approach involves organizing code so that the compiler never sees the incompatible import during a specific build:

src/
  common.gleam          > Target-agnostic logic and types
  erlang_impl.gleam     > BEAM-specific code
  js_impl.gleam         > Node/Browser-specific code

Assumptions and Limitations

This strategy assumes you are not looking for a language-level conditional preprocessor (like #ifdef in C), which does not currently exist in Gleam. The architecture relies on the developer to ensure that the target-specific modules are only called by the intended runtime logic.

To verify your setup, run the build for both targets:

gleam build --target erlang
gleam build --target javascript