Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt

Use this file to discover all available pages before exploring further.

The export directive in Dart is a library-level declaration used to re-expose the public API of another library. By utilizing this directive, a library can forward the public members (classes, functions, variables, typedefs) of a specified Uniform Resource Identifier (URI) to any external library that imports it, effectively merging namespaces.

​
Syntax

The fundamental syntax requires the export keyword followed by a string literal representing the URI of the target library. 
export 'path/to/library.dart';
export 'package:module/library.dart';

​
Combinators

To control namespace pollution and resolve potential naming collisions, the export directive supports combinators. These modifiers restrict exactly which members are re-exposed to the consuming library.
  • show (Whitelist): Restricts the export to only the explicitly declared identifiers.
  • hide (Blacklist): Exports all public members of the target library except the explicitly declared identifiers.
// Exports only the 'StringUtil' and 'MathUtil' classes
export 'package:utils/utils.dart' show StringUtil, MathUtil;

// Exports all public members except 'InternalConfig'
export 'package:core/core.dart' hide InternalConfig;

​
Conditional Exports

Dart supports conditional exports to evaluate configuration environment constants at compile-time and dynamically determine which URI to export. The compiler evaluates the if conditions sequentially and exports the URI of the first condition that evaluates to true. If no conditions are met, it resolves the default URI declared before the conditions. 
export 'src/stub_implementation.dart'
    if (dart.library.io) 'src/io_implementation.dart'
    if (dart.library.html) 'src/web_implementation.dart';

​
Scope and Visibility Rules

  1. Public Members Only: The export directive strictly applies to public members. Any identifier prefixed with an underscore (_), which denotes library privacy in Dart, is inherently excluded from the export process.
  2. Local Scope Isolation: Declaring an export does not introduce the target library’s members into the lexical scope of the exporting file. If the exporting file needs to reference those members internally, it must declare a separate import directive for the same URI.
// Re-exposes 'NetworkClient' to external consumers
export 'src/network_client.dart';

// Required to instantiate or reference 'NetworkClient' within this specific file
import 'src/network_client.dart';
  1. Transitive Exporting: Exports are transitive. If Library A exports Library B, and Library B exports Library C, any library importing Library A will have access to the public APIs of both Library B and Library C.
  2. Name Collisions: Dart strictly enforces export namespaces. If a library exports multiple URIs that contain identical public identifiers, Dart will throw an ambiguous_export compile-time error directly in the file containing the conflicting export directives. This error occurs immediately upon compilation, regardless of whether a consuming library attempts to use the identifier. This ambiguity must be resolved at the export level using show or hide combinators to ensure a clean, unified namespace.
// Assuming both libraries contain a 'Logger' class, 
// the 'hide' combinator prevents an ambiguous_export compile-time error:
export 'src/file_logger.dart' hide Logger;
export 'src/console_logger.dart';
Master Dart with Deep Grasping Methodology!Learn More