> ## 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 Part Directive
The `part` directive in Dart is a compilation mechanism that splits a single logical library across multiple physical files. When files are joined using `part` and `part of`, the Dart compiler treats them as a single contiguous entity. Consequently, all files within this relationship share the exact same **library scope**, granting them unrestricted access to each other's private members (identifiers prefixed with an underscore `_`).
## Modern Context and Style Guide
In modern Dart development, the primary application of the `part` directive is **code generation** (e.g., integrating generated files from tools like `build_runner`, `freezed`, or `json_serializable`). The official Dart style guide strongly discourages manually splitting hand-written code using `part`. For organizing hand-written code, the recommended approach is to use multiple independent libraries and expose them using `export` directives.
## Syntax and File Relationship
The implementation requires a bidirectional link between a parent library file and its subordinate part files.
**1. The Parent File (`part`)**
The parent file acts as the root of the library. It must contain all `import` and `export` directives required by any of its parts. It uses the `part` keyword followed by a relative URI string to declare its subordinate files.
```dart theme={"dark"}
// parent_library.dart
library parent_library; // Optional library declaration
import 'dart:math'; // Dependency shared with part files
// Link to the subordinate file
part 'subordinate_file.dart';
class ParentClass {
// Private member, visible to all files in the same library scope
final int _privateParentField = 42;
}
```
**2. The Subordinate File (`part of`)**
The subordinate file cannot contain any `import` or `export` directives. It must begin with the `part of` directive, pointing back to the parent file. Modern Dart prefers using the parent file's URI, though referencing the parent's library name is also syntactically valid.
```dart theme={"dark"}
// subordinate_file.dart
// Points back to the parent file via URI (Preferred)
part of 'parent_library.dart';
// Alternatively, pointing back via library name (Legacy)
// part of parent_library;
class SubordinateClass {
void accessParentAndDependencies() {
final parent = ParentClass();
// Direct access to the parent's private library scope
final value = parent._privateParentField;
// Utilizing the import (dart:math) declared in the parent file
final calculated = max(value, 100);
print(calculated);
}
}
```
## Technical Constraints
* **Single Point of Entry for Dependencies:** All `import` statements required by any part file must be declared exclusively in the parent file. The Dart analyzer will throw a compilation error if an `import` is placed inside a file declared as a `part`.
* **Strict Bidirectionality:** A file declared as a `part` in a parent file must contain a corresponding `part of` directive pointing back to that specific parent. An orphaned part file cannot be compiled independently.
* **Directive Ordering:** The `part` directives must appear after all `import` and `export` directives in the parent file, but before any actual code declarations (classes, functions, variables).
* **Transitive Privacy:** Because the files are evaluated as a single library, the concept of "file-private" does not exist between them; privacy in Dart is strictly "library-private".
Tired of Poor Dart Skills? Fix That With Deep Grasping!
Learn More
