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 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. 
// 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. 
// 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”.
Master Dart with Deep Grasping Methodology!Learn More