|
| 1 | +--- |
| 2 | +description: Package architecture of ts-graphviz. |
| 3 | +--- |
| 4 | +# Package Architecture |
| 5 | + |
| 6 | +**ts-graphviz** consists of several packages, each with a specific role: |
| 7 | + |
| 8 | +- **`ts-graphviz`** (Main Package): Provides high-level APIs for creating and manipulating graphs, suitable for most users. |
| 9 | + |
| 10 | +- **`@ts-graphviz/core`**: Contains core implementations of models and functions, used internally and available for advanced use. |
| 11 | + |
| 12 | +- **`@ts-graphviz/common`**: Aggregates Graphviz domain knowledge, providing type definitions, constants, and utilities. Supports use cases like extending custom types and attributes. |
| 13 | + |
| 14 | +- **`@ts-graphviz/ast`**: Offers tools for parsing, manipulating, and generating DOT language graphs at the AST level. |
| 15 | + |
| 16 | +- **`@ts-graphviz/adapter`**: Executes Graphviz commands in various runtime environments (Node.js, Deno) and converts DOT strings to images. |
| 17 | + |
| 18 | +- **`@ts-graphviz/react`**: Allows defining graphs using React's declarative UI paradigm, expressing DOT language models with JSX. |
| 19 | + |
| 20 | +## Exposing Internal Modules as Submodules |
| 21 | + |
| 22 | +**ts-graphviz** publishes some of its internal modules as submodules within the main package. Specifically, the following import paths are available to access these internal modules: |
| 23 | + |
| 24 | +- **`ts-graphviz/ast`** or **`@ts-graphviz/ast`** |
| 25 | +- **`ts-graphviz/adapter`** or **`@ts-graphviz/adapter`** |
| 26 | + |
| 27 | +This allows users to choose the module import style that best fits their project's needs. By using the `ts-graphviz/<module-name>` style, you can limit your dependencies to the `ts-graphviz` library itself, with internal packages (e.g., `@ts-graphviz/adapter`, `@ts-graphviz/ast`) being managed centrally by the `ts-graphviz` package. On the other hand, using the `@ts-graphviz/<module-name>` style enables you to manage dependencies on a per-module basis, allowing you to selectively install specific modules as needed. |
| 28 | + |
| 29 | +:::tip Managing Dependencies When Choosing Import Paths |
| 30 | + |
| 31 | +When using package managers that enforce strict dependency management (e.g., pnpm), the choice of import path can significantly impact how dependencies are handled. Consider the following points: |
| 32 | + |
| 33 | +- **Using `ts-graphviz/<module-name>` Style**: |
| 34 | + - **Advantages**: Limits dependencies to the `ts-graphviz` library itself, with internal packages (e.g., `@ts-graphviz/adapter`, `@ts-graphviz/ast`) being managed centrally by the `ts-graphviz` package. This prevents dependency conflicts and ensures that stable versions recommended by the library are used. |
| 35 | + - **Recommended Scenarios**: When you want to minimize dependencies or when the internal packages managed by `ts-graphviz` do not have specific version requirements. |
| 36 | + |
| 37 | +- **Using `@ts-graphviz/<module-name>` Style**: |
| 38 | + - **Advantages**: Allows you to manage dependencies on a per-module basis, installing only the specific modules you need, which can help keep your application lightweight. |
| 39 | + - **Caveats**: Requires you to manage internal dependencies (e.g., `@ts-graphviz/adapter`, `@ts-graphviz/ast`) separately within your package manager. This can complicate version management. |
| 40 | + - **Recommended Scenarios**: When you need to use specific modules only or require detailed control over your dependencies. |
| 41 | + |
| 42 | +**Summary**: |
| 43 | +- If you prefer **simple dependency management**, use the `ts-graphviz/<module-name>` style. |
| 44 | +- If you require **fine-grained control over dependencies** or only need specific modules, opt for the `@ts-graphviz/<module-name>` style. |
| 45 | + |
| 46 | +This approach allows you to manage dependencies in a way that best suits your project's requirements. |
| 47 | +::: |
| 48 | + |
| 49 | + |
| 50 | +The relationships between packages can be visualized as follows: |
| 51 | + |
| 52 | + |
| 53 | + |
| 54 | +This modular architecture ensures: |
| 55 | + |
| 56 | +- **Maintainability**: Individual packages can be maintained and updated without affecting others. |
| 57 | + |
| 58 | +- **Flexibility**: Users can select only the packages needed for their specific use cases. |
| 59 | + |
| 60 | +- **Extensibility**: Facilitates the addition of new features or packages as the library evolves. |
0 commit comments