Gleam 1.0 target compatibility for erlang and javascript standard library modules

Target-Specific Standard Library Access

Gleam 1.0 provides distinct compiler targets for Erlang and JavaScript. While the core language is stable, the standard library contains modules specifically gated to a single runtime, such as gleam/erlang/process for the BEAM and gleam/javascript for JS environments.

Cross-Target Library Constraints

When developing a library intended to support both targets, importing a target-specific module causes a compilation error when the alternative target is selected. There is currently no native polyfill mechanism within the standard library to abstract these runtime-specific behaviors into a single interface.

Given these constraints, what is the recommended pattern for managing conditional imports or providing target-agnostic abstractions for these modules? Does the current architecture support a specific strategy for maintaining a single codebase that targets both the BEAM and JavaScript without duplicating logic?