> ## 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.
# Dart Export Directive
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.
```dart theme={"dark"}
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.
```dart theme={"dark"}
// 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.
```dart theme={"dark"}
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.
```dart theme={"dark"}
// 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';
```
3. **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.
4. **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.
```dart theme={"dark"}
// 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';
```
Tired of Poor Dart Skills? Fix That With Deep Grasping!
Learn More
