Transpile
Overview
Transpiling converts a modularized ADITO project into a flat, standalone project ready for deployment. This process resolves all modifications, ExtensionPoints, and service implementations into a unified, deployable codebase. The transpiled output is stored in the project's dist
folder.
The transpiler generates an unmodularized standalone project similar to the original pre-modularization structure by using the content of the folder appendix_title. Deployment is always performed using this transpiled project in the dist
folder.
Usage
You can start a transpile operation using the "hammer" button in the Designer’s button bar (for partial transpile) or from the project’s context menu (for partial or full transpile):
Transpile Modes
-
Full Transpile: Processes all files in the project, generating a complete transpiled output.
-
Partial Transpile: Processes only files changed since the last transpile. If changes cannot be handled incrementally or if an error occurred during the last transpile, a full transpile is triggered automatically.
How Transpiling Works
The transpiler creates the final code by resolving all modifications, ExtensionPoints, and services according to file type:
-
In
.aod
files, the<ExtensionPoint>
XML tag is replaced by all corresponding tags from the modules. -
Calls to
modules.loadService()
are resolved into an array containing all service implementations, followed by an iterative function call. Implementation functions are appended at the end of the file with generated names. (See chapter Services for details and examples.)
Although transpiling is typically performed on modules of type "project," it can also be done on modules of type "module" without subsequent deployment. This can be useful for:
-
Inspecting the transpiled result of a specific modification or service.
-
Manually exchanging content during local development.
Configuration
.transpilerignore
Similar to .gitignore
, the .transpilerignore
file excludes specific files or folders from the transpiling process (see chapter Transpile).
This file must be located at the root of the project’s file structure—at the same level as package.json
.
Example .transpilerignore
content:
# Git
.git
.gitignore
.gitattributes
.gitlab-ci.yml
README.md
# ADITO
.aditoprj
dist
others
jsconfig.json
jsconfig.template.json
.eslintrc.json
# NPM
node_modules
package.json
package-lock.json
.npmrc
Conflict Handling
Ambiguity Through Multiple Dependencies ("Diamond Problem")
A modification conflict can occur when multiple dependent modules modify the same property of a shared base module. This creates ambiguity during the transpile process, because the system cannot determine which modification to apply. This situation resembles the "diamond problem" in multiple inheritance but occurs here due to unresolved dependency paths.
Consider the following scenario:
In this example, both Module B and Module C modify the same property mainView
of the shared data model MyContextA
defined in Module A.
If Module D depends on both B and C, the transpiler encounters ambiguity: it cannot determine whether mainView
should resolve to Module_B_Main_view
or Module_C_Main_view
.
This results in a transpile error because multiple conflicting modifications exist for the same property.
Resolution
To resolve this ambiguity, Module D must define its own explicit modification of MyContextA.mainView
.
- use a existing assignment:
mainView = Module_B_Main_view
ormainView = Module_C_Main_view
- create a new assignment:
mainView = Module_D_Main_view
Logging
To enable transpiler-specific logging, add the following JVM parameter to the ADITODesigner.conf
file:
-J-Dadito.modularization.logging.debug
This activates debug-level output related to the modular transpilation process.
Virus Scanner Configuration
Virus scanners can significantly slow down various ADITO operations, especially the transpile process. To improve performance, consider adding appropriate exclusions to your virus scanner configuration—provided this complies with your organization's security policies.
Excluding the ADITO project directory (especially its dist
and node_modules
subfolders) can reduce unnecessary scanning overhead during transpilation and file generation.