Transforming a sizeable Typescript undertaking into ES6 modules

Question

Transforming a sizeable Typescript undertaking into ES6 modules

I am faced with the challenge of transitioning a fairly large app (~650 files) that currently has a mix of ES6 modules and legacy global namespace internal modules and classes.

My goal is to convert everything to 100% ES6 modules.

Considering an Iterative Approach

To achieve this, I first need to convert all the global objects to ES6 modules by adding the "export" keyword.

However, as soon as I add "export", the global object becomes non-global and each file using that object will throw a compiler error "object not found" (i.e. Cannot read property 'xxx' of undefined).

To resolve this issue, I must add an "import" statement to the file, thereby switching it to an ES6 module which in turn removes the global status of all objects in that file, causing new "object not found" errors in other files.

In essence, this incremental approach seems to have its drawbacks.

Potential Simpler Solution:

Go through all ts files
1. Add export to all top-level classes, modules, and variables programmatically.
2. Compile these into a list.
Create a barrel (globalBarrel) file that re-exports all the exports gathered in the previous step.

Revisit all ts files

Add

import {list, of, symbols, exported, by, the, barrel,file} from "./globalBarrel"

to each file.

Attempt a clean compilation?
1. Expect some circular dependency issues which need to be resolved.
For future file edits, utilize the vsCode "Organize Imports" command to eliminate unnecessary imports.

As quoted by @jfriend000:

Trying to automatically convert non-modular code into modules will likely result in chaos.

Transitioning everything to modules at once could simplify the true modularization process.

Questioning the Best Approach

Is this method the most effective? Any suggestions?

typescript es6-modules

Answer 1

Answer №1

To progress towards this goal, I must first transform all the global objects into ES6 modules by introducing the "export" keyword.

However, once the "export" is added, the global object loses its global status, resulting in a compiler error in every file that utilizes that object; specifically, a "Cannot read property 'xxx' of undefined" error.

To address this issue, an "import" statement needs to be incorporated into the file, effectively converting it into an ES6 module. Consequently, this action further decentralizes all the objects within that file, leading to additional "object not found" errors in other files.

Indeed, the key to breaking free from this frustrating cycle is to assign each converted file to a global variable whenever you convert it into a module. This will allow referencing from non-module files without necessitating their conversion. Although this approach involves some boilerplate code, a proposed solution (found here) could potentially streamline this process.

Possibly, your current setup employs a bundling tool to guarantee that all non-module files are loaded and contribute to a unified global scope for mutual access to definitions. Begin by creating a file containing the following script and configure your bundler to prioritize its execution:

namespace Modules {
    // Ensure `Modules` is established during runtime.
    (() => {})();
}

Assuming you have the initial setup as follows:

// a.ts
namespace A {
    export const a = 42;
}

// b.ts
namespace B {
    console.log(A.a);
}

You can transition to the modified version below:

// a.ts
export const a = 42;

import * as A_ from "./a";
declare global {
    namespace Modules {
        export import A = A_;
    }
}
Modules.A = A_;

// b.ts
namespace B {
    console.log(Modules.A.a);
}

Subsequently, b.ts will gain the capability to access Modules.A with complete type information without being converted into a module itself (barring any load order complications with the bundler).

Answer 2

To progress towards this goal, I must first transform all the global objects into ES6 modules by introducing the "export" keyword.

However, once the "export" is added, the global object loses its global status, resulting in a compiler error in every file that utilizes that object; specifically, a "Cannot read property 'xxx' of undefined" error.

To address this issue, an "import" statement needs to be incorporated into the file, effectively converting it into an ES6 module. Consequently, this action further decentralizes all the objects within that file, leading to additional "object not found" errors in other files.

Indeed, the key to breaking free from this frustrating cycle is to assign each converted file to a global variable whenever you convert it into a module. This will allow referencing from non-module files without necessitating their conversion. Although this approach involves some boilerplate code, a proposed solution (found here) could potentially streamline this process.

Possibly, your current setup employs a bundling tool to guarantee that all non-module files are loaded and contribute to a unified global scope for mutual access to definitions. Begin by creating a file containing the following script and configure your bundler to prioritize its execution:

namespace Modules {
    // Ensure `Modules` is established during runtime.
    (() => {})();
}

Assuming you have the initial setup as follows:

// a.ts
namespace A {
    export const a = 42;
}

// b.ts
namespace B {
    console.log(A.a);
}

You can transition to the modified version below:

// a.ts
export const a = 42;

import * as A_ from "./a";
declare global {
    namespace Modules {
        export import A = A_;
    }
}
Modules.A = A_;

// b.ts
namespace B {
    console.log(Modules.A.a);
}

Subsequently, b.ts will gain the capability to access Modules.A with complete type information without being converted into a module itself (barring any load order complications with the bundler).

Answer 3

Answer №2

Do you think this approach is the most effective? Any ideas for improvement?

I have my doubts about the viability of this method, and I strongly believe it is far from the optimal solution.

Attempting to transform non-modular code into modules through automated processes will likely result in a chaotic outcome. While it may be possible to accomplish, the end result will only complicate matters further. Instead of enhancing your architecture, you will essentially be forcing a non-modular structure into a tangled web of interdependent modules. Complexity will increase rather than decrease.

A more sensible strategy would involve gradually redesigning specific areas of functionality to truly become modular. Create interfaces for different functionalities, package them as modules, and then systematically transition all users to import these interfaces. This can be done step by step, one area at a time. There's no need to overhaul the entire system at once and then struggle to reassemble everything.

Eradicating shared global variables requires a fundamental redesign of the system. Simply consolidating globals into a module that every part of the code must import does not enhance the design. If anything, it exacerbates the intertwined and dependent nature of the code.

The incremental modular redesign approach allows for a more manageable process. By focusing on one functional area at a time, you can gradually untangle the complexity without creating a massive mess. If the code heavily relies on global variables scattered throughout, significant redesign efforts will be necessary. This may involve creating data-containing objects or transferring global data into relevant modules with exported accessors.

Answer 4

Do you think this approach is the most effective? Any ideas for improvement?

I have my doubts about the viability of this method, and I strongly believe it is far from the optimal solution.

Attempting to transform non-modular code into modules through automated processes will likely result in a chaotic outcome. While it may be possible to accomplish, the end result will only complicate matters further. Instead of enhancing your architecture, you will essentially be forcing a non-modular structure into a tangled web of interdependent modules. Complexity will increase rather than decrease.

A more sensible strategy would involve gradually redesigning specific areas of functionality to truly become modular. Create interfaces for different functionalities, package them as modules, and then systematically transition all users to import these interfaces. This can be done step by step, one area at a time. There's no need to overhaul the entire system at once and then struggle to reassemble everything.

Eradicating shared global variables requires a fundamental redesign of the system. Simply consolidating globals into a module that every part of the code must import does not enhance the design. If anything, it exacerbates the intertwined and dependent nature of the code.

The incremental modular redesign approach allows for a more manageable process. By focusing on one functional area at a time, you can gradually untangle the complexity without creating a massive mess. If the code heavily relies on global variables scattered throughout, significant redesign efforts will be necessary. This may involve creating data-containing objects or transferring global data into relevant modules with exported accessors.

Transforming a sizeable Typescript undertaking into ES6 modules

Considering an Iterative Approach

Potential Simpler Solution:

Questioning the Best Approach

Answer №1

Answer №2

Similar questions

The Vue Router hooks are not being activated within the component when utilizing Typescript

Retrieve the final variable in an Observable sequence

Utilizing TypeScript to spread properties onto a component and destructure them from within components

Having trouble accessing functions within the webpack bundle

Error message: The module cannot be found by the compiler. This issue is resolved when using Visual Code and Definitely

Exploring Angular2's DOMContentLoaded Event and Lifecycle Hook

Is there a method to reduce the requirement for if-conditions in this situation?

What is the best way to retrieve app.state in a Remix project when running a Cypress test?

Exploring nested promises in TypeScript and Angular 2

The functionality to generate personalized worldwide timezone pipe is not functioning

I'm having trouble with one of my filter pipes not displaying any results. Can anyone help me troub

Error message while attempting to update devextreme-datagrid: "Received HTTP failure response for an unknown URL: 0 Unknown Error"

Differing preferences for indentation styles can lead to conflicting prett

Tips for aligning the types of objects transmitted from a Web API backend to a React/Redux frontend

What is the method for incorporating sorting into a mat-list?

Retrieving the selected date from mat-datepicker into a FormControl

Encountered an issue during the transition from Angular 7 to Angular 9

exit out of React Dialog using a button

Distinguish between two varieties using parameters

The Typescript Select is displaying an incorrect value