Upgrade

JDito Upgraders in Modularization

When modularizing a project, developers often need to:

• Rename functions;
• Move specific functions from one library to another (for example, relocating dependency-related functions to a module-specific library).

To streamline this process and avoid manually updating all function calls and corresponding import statements, JDito provides upgraders. JDito upgraders are JSON configuration files that map old function calls to their new counterparts.

info

JDito upgraders only modify function calls and related imports after the functions have been moved or renamed manually by the developer. They do not move or rename functions themselves.

Locating and Executing JDito Upgraders

All upgrader files for a module are located in the others folder of the project tree. These files may be directly under others or within a subfolder named upgraders.

To execute JDito upgraders:

1. Right-click the root node of your project or module in the project tree.
2. Select the option "Upgrade JDito…" from the context menu.

Figure: JDito upgrade option in the context menu

3. Choose the path to your module/project, a folder, or a specific upgrader file:
   • Selecting a folder executes all upgrader files within that folder.
   • Selecting a single upgrader file executes only that file.

tip

It is recommended to select the root node of your project/module to process all upgrader files, including those of dependencies located in the node_modules folder.

For related information, see the section "Upgrade from unmodularized libraries in customer projects to modularized libraries" in the appendix appendix_title.

---

JDito Upgrader Types

JDito supports various upgrader types, each serving a specific purpose. Below is a detailed explanation of each type with examples.

STATICFUNCTION_MOVED

Changes the first part of a static function’s name, typically when the function is moved to a different class or utility.

Example:

{
  "type": "STATICFUNCTION_MOVED",
  "base": "myFunctionName",
  "oldName": "OldClass",
  "newName": "NewClass",
  "imports": {
    "NewClass": [
      "NewClass_lib"
    ]
  }
}

Meaning:
OldClass.myFunctionName() → NewClass.myFunctionName()

---

STATICFUNCTION_RENAMED

Changes the second part of a static function’s name, i.e., the function name itself within the same class.

Example:

{
  "type": "STATICFUNCTION_RENAMED",
  "base": "EventHandler",
  "oldName": "oldExportFunctionName",
  "newName": "newExportFunctionName"
}

Meaning:
EventHandler.oldExportFunctionName() → EventHandler.newExportFunctionName()

---

GLOBALFUNCTION_RENAMED

Renames a global function and updates the import accordingly.

Example:

{
  "type": "GLOBALFUNCTION_RENAMED",
  "oldName": "newSelect",
  "newName": "newNewSelect",
  "oldImportName": "Sql_lib",
  "newImportName": "NewSql_lib"
}

Meaning:
newSelect() → newNewSelect(), with import changed from Sql_lib to NewSql_lib

---

PROPERTY_RENAMED

Renames a property of an object, including updating the import if necessary.

Example:

{
  "type": "PROPERTY_RENAMED",
  "base": "COMBO.databaseField",
  "oldName": "AttributeTypes",
  "oldImportName": "Attribute_lib",
  "newName": "New_AttributeTypes",
  "newImportName": "New_Attribue_lib"
}

Meaning:
COMBO.databaseField.AttributeTypes → COMBO.databaseField.New_AttributeTypes

---

IMPORT

Updates import statements without changing function calls.

Example:

{
  "type": "IMPORT",
  "base": "SqlBuilder",
  "oldImportName": "Sql_lib",
  "newImportName": "SqlBuilder_lib"
}

Meaning:
Import of SqlBuilder changes from Sql_lib to SqlBuilder_lib.

---

MEMBERFUNCTION_TO_STATICFUNCTION

Converts a member function call into a static function call, often used when the function is moved outside the original object.

Example:

{
  "type": "MEMBERFUNCTION_TO_STATICFUNCTION",
  "oldName": "getReplacedEmailsByContactIds",
  "newName": "getReplacedEmailsByContactIds",
  "base": "EmailUtils",
  "imports": {
    "EmailUtils": [
      "Email_lib"
    ]
  }
}

Meaning:
template.getReplacedEmailsByContactIds([pContactId], pAdditionalPlaceholders);
→
EmailUtils.getReplacedEmailsByContactIds(template, [pContactId], pAdditionalPlaceholders);

---

REGEX

Allows arbitrary code replacement using regular expressions.

Example:

{
  "type": "REGEX",
  "search": "Foo\\.(.*)",
  "replace": "Foo.($1)_NEW",
  "imports": {
    "Foo": [
      "Foo_lib"
    ]
  }
}

Meaning:
Replaces all occurrences matching Foo.<something> with Foo.<something>_NEW.

---

Example Upgrader File

{
  "elements": [
    {
      "type": "STATICFUNCTION_MOVED",
      "base": "getDSGVOAnonymizeOrganisationId",
      "oldName": "OrgUtils",
      "newName": "DataPrivacyUtils",
      "imports": {
        "DataPrivacyUtils": [
          "DataPrivacy_lib"
        ]
      }
    }
  ]
}

When this upgrader is applied, the import statement in all .js files that call getDSGVOAnonymizeOrganisationId will be updated to:

import { DataPrivacyUtils } from "DataPrivacy_lib";

warning

JDito upgraders do not automatically remove old imports. After running an upgrader, it is recommended to clean up unused imports using ESLint autofix:

npx eslint "**/*.js" --ignore-pattern node_modules/ --fix

---

Creating a New Upgrader File

Currently, the context menu in the others folder does not provide an option to create a new upgrader file. To create one:

1. Copy an existing upgrader file.
2. Rename the copy following the spelling conventions, for example:
   Activity_lib_Upgrader.json
3. Modify the content according to your requirements.

Alternatively:

• Create a new text file via your file explorer.
• Rename it following the spelling conventions, for example:
  CreateNewActivity_Upgrader.json

You can edit upgrader files using the Designer’s code editor or any external editor such as VS Code.

tip

It is recommended to organize all upgrader files of a module in a subfolder named upgraders under the others folder. If this folder does not exist, create it manually at the file system level.

---