• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1# Overview of Modular Operation
2
3To address challenges of large and complex application development—such as increased package size due to multiple copies of code during compilation, file dependencies, difficulties in sharing code and resources, and pollution of singletons and global variables—ArkTS supports modular compilation, packaging, and running. This approach not only streamlines the development process but also facilitates easier code writing and feature maintenance.
4
5Modularization is the process of organizing ArkTS/TS/JS modules (where each file corresponds to a module), including so modules, and then [loading](#loading-process-of-modular-operation), parsing, combining, and executing these modules through compilation tools or runtime mechanisms.
6
7ArkTS supports various module types, including ETS/TS/JS files, JSON files, and native modules. It adheres to both [ECMAScript module specifications](#ecmascript-module) and [CommonJS module specifications](#commonjs-module). In addition, ArkTS extends loading modes to include [dynamic import](arkts-dynamic-import.md), static import, [lazy import](arkts-lazy-import.md), [synchronous dynamic loading of native modules](js-apis-load-native-module.md), and [loading files using Node-API](load-module-base-nodeapi.md).
8
9## Loading Process of Modular Operation
10
11ArkTS modular operation is implemented according to the ECMAScript module specification and executes modules using a post-order traversal method: starting from the leftmost subtree of the module graph, it executes the modules, then their peers, and finally their parents. This algorithm runs recursively until it reaches the root of the module graph.
12
13For example, in the figure below, each parent node loads its corresponding child nodes and executes peers in the order specified by the **import** statements. The execution order for the module graph files is as follows: D->F->G->E->B->I->H->C->A.
14
15![image_0000002043487154](figures/image_0000002043487154.png)
16
17Here, file A is referred to as the entry file, which is the starting point for execution. Certain built-in interfaces for loading content, such as [windowStage.loadContent](../reference/apis-arkui/arkts-apis-window-Window.md#loadcontent9) and [Navigation](../ui/arkts-navigation-navigation.md), will also be executed as entry files, especially when these files are not loaded using the **import** syntax.
18
19Starting from file A, a complete set of files will be loaded, including file A, files on which file A depends, and subsequently dependent files, until the leaf nodes of each branch is reached.
20
21A regular module is loaded once in the same thread and multiple times in different threads, creating a new module object in each thread. If you only want to load the module once in a process, use the [shared module](./arkts-sendable-module.md).
22
23## Modular Specifications Supported by ArkTS
24
25### ECMAScript Module
26
27ECMAScript modules (ES modules) are a module feature implemented in JavaScript starting from ECMAScript 6.0, standardized in the ECMAScript® 2025 Language Specification (tc39.es). The module functionality is composed of two commands: **export** and **import**.
28
29For details about how to use **export** and **import** in ArkTS, see [ArkTS Introduction](../quick-start/introduction-to-arkts.md#modules).
30
31### CommonJS Module
32
33CommonJS modules were proposed as a standard by the JavaScript community in 2009 and first partially adopted and implemented in Node.js. CommonJS treats each file as a module, with the **module** variable representing the current module. **module.exports** is the variable exported by the module, and each module also has an **exports** variable (exports === module.exports).
34
35The following table lists the module import and export syntax.
36
37| Loading Type| Module Import| Module Export (Do Not Mix module.exports with exports)|
38| -------- | -------- | -------- |
39| Variable| const ohos = require('ohos') | exports.add = add or module.exports.name = name |
40| Variable| const ohos = require('ohos') | module.exports = add |
41| Function| const ohos = require('ohos')<br>ohos.fun(); | exports.fun = function foo () {} or module.exports.fun = function foo () {} |
42
43> **NOTE**
44>
45> CommonJS modules can be used only to export third-party packages. They cannot be created or used in projects.
46
47
48### Compatibility Between CommonJS and ES Modules
49
50The following table lists the compatibility between CommonJS and ES modules, with the import and export syntax following their respective specifications:
51| Inter-Module Reference| ES Module Export| CommonJS Export|
52| -------- | -------- | -------- |
53| ES Module Import| Supported| Supported|
54| CommonJS Import| Not supported| Supported|
55
56## Module Types Supported by ArkTS
57
58### ETS/TS/JS
59
60Loading of the ETS, TS, and JS modules complies with the [ECMAScript module specifications](#ecmascript-module) and [CommonJS module specifications](#commonjs-module).
61
62### JSON File
63
64JavaScript Object Notation (JSON) is a lightweight data interchange format that uses a text-based format independent of any programming language to store and represent data.
65
66JSON files can only be imported using the **default** method, as shown below:
67
68```
69import data from './example.json'
70```
71
72### Native Module
73
74The syntax specifications for importing and exporting the native module (.so) are the same as those for loading the ETS, TS, and JS files. Native modules (.so files) follow the same import/export and loading syntax as ETS/TS/JS modules. For details, see [Statically Loading Native Modules](./arkts-import-native-module.md).
75
76> **NOTE**
77>
78> Native modules cannot be imported to CommonJS modules.
79
80Example:
81
82```
83// index.d.ts corresponding to libentry.so
84export const add: (a: number, b: number) => number;
85```
86
87```
88// test.ets
89import { add } from 'libentry.so'
90add(2, 3)
91```
92
93Currently, ArkTS does not support namespaces for native module exports or imports.
94
95Anti-example:
96
97```
98// test1.ets
99export * from 'libentry.so'  // Use the namespace to export data.
100```
101
102```
103// test2.ets
104import('./test1').then((ns:ESObject) => {
105  // The ns object cannot be obtained during dynamic import.
106  // To use this method to load native modules, change the export in test1.ets to named or default export.
107})
108```
109
110> **NOTE**
111>
112> You are not advised to import data using import \* as xxx from 'xxx'. This import mode will cause runtime exceptions. Default imports are recommended.
113