Using TypeScript absolute imports from another project for standard TypeScript files and declarations at a global scope

Question

Using TypeScript absolute imports from another project for standard TypeScript files and declarations at a global scope

We are currently considering migrating a large JavaEE code base to TypeScript. Within this environment, there are multiple projects with intricate directory structures and JavaScript code that heavily relies on global variables across all projects.

Although TypeScript does offer multi-project support, as showcased in this small example on GitHub, our situation is more complex.

(1) The JS code is deeply embedded within the projects, for instance "Project1/src/main/resources/de/mycompany/webapp/ts". The resulting JS code should then be located at "Project1/src/main/resources/de/mycompany/webapp/ts-generated". TypeScript provides options like rootDir and outDir to handle this scenario.

(2) Due to the intricate folder structure, using relative imports is not feasible. For example, referencing a file from the 'core' project should have a consistent approach, regardless of whether it is accessed from the 'ui' or 'ui-utils' project. TypeScript introduces "baseUrl" and "paths" for absolute references, yet implementation seems challenging in a multi-project setup (or perhaps an error on our end). An example would be wanting to

import * from '@core/utils/mycode.ts'

, where this reference should align with the 'core' project's baseUrl or rootDir.

(3) There is a need to make connections to existing JS code in the global scope. TypeScript addresses this by providing declaration files (.d.ts) which can enhance the compiler's understanding through additional type information. Therefore, our plan involves generating declaration files for the current JS codebase, following by importing these declarations into consuming TypeScript projects. Nevertheless, we've encountered challenges where the import-keyword in TypeScript consistently imports declarations as a module with a namespace, despite the intention to link the JS objects to the global scope. We came across the concept of Triple-Slash import, which appears effective for relative references but lacks support for absolute references spanning different projects.

Questions

Regarding point (2): Is there a way to enable absolute imports across projects, preferably starting from baseUrl or rootDir?

Concerning point (3): Can TypeScript declarations from other projects be imported (or referenced) for JS code present in the global scope? It's crucial to note that the goal here isn't to generate code, but solely to inform the compiler about the existence of specific code.

typescript import declaration multi-project

Answer 1

Answer №1

Concerning (3)

In order to incorporate global scope type declarations (.d.ts files) in TypeScript, you can utilize the "typeRoots" array in tsconfig.json: "typeRoots" : ["./typings"]. It is important to note that these files must also be accessible from paths specified in the "include" array ("include": ["./typings/*.ts"]).

This functionality is made possible because the paths defined in "typeRoots" and "include" can reference directories outside the current project.

Concerning (2)

It appears that achieving this with a single call to the TypeScript compiler may not be feasible. However, it can be accomplished by compiling projects sequentially based on their dependencies.

For instance, assuming that a project P1, which has no dependencies, has already been compiled. The objective now is to compile the project P2, which relies on code from P1. In the given scenario, the "outDir" of P1 is designated as "build":

Include all ts files from the "outDir" of P1 using the "includes" array of P2.
- "include": ["../P1/build/*.ts"]
- This ensures that the compiled d.ts files from P1 are accessible in P2, enabling the TypeScript compiler to recognize the code from P1.
Add a path alias to the "outDir" of P1 via the "paths" array of P2.
- ```
"paths": { "@P1/*": ["../P1/build/*"] }
```
- This enables absolute imports to function correctly.

This approach works due to the fact that the paths specified in the "paths" and "includes" arrays can refer to directories beyond the current project.

It should be noted that this method does not leverage the Project References feature of TypeScript. Additionally, unless there is a requirement to provide type information for plain JS code, typeRoots are unnecessary as the type information should already exist in the "outDir" of P1.

Answer 2

Concerning (3)

In order to incorporate global scope type declarations (.d.ts files) in TypeScript, you can utilize the "typeRoots" array in tsconfig.json: "typeRoots" : ["./typings"]. It is important to note that these files must also be accessible from paths specified in the "include" array ("include": ["./typings/*.ts"]).

This functionality is made possible because the paths defined in "typeRoots" and "include" can reference directories outside the current project.

Concerning (2)

It appears that achieving this with a single call to the TypeScript compiler may not be feasible. However, it can be accomplished by compiling projects sequentially based on their dependencies.

For instance, assuming that a project P1, which has no dependencies, has already been compiled. The objective now is to compile the project P2, which relies on code from P1. In the given scenario, the "outDir" of P1 is designated as "build":

Include all ts files from the "outDir" of P1 using the "includes" array of P2.
- "include": ["../P1/build/*.ts"]
- This ensures that the compiled d.ts files from P1 are accessible in P2, enabling the TypeScript compiler to recognize the code from P1.
Add a path alias to the "outDir" of P1 via the "paths" array of P2.
- ```
"paths": { "@P1/*": ["../P1/build/*"] }
```
- This enables absolute imports to function correctly.

This approach works due to the fact that the paths specified in the "paths" and "includes" arrays can refer to directories beyond the current project.

It should be noted that this method does not leverage the Project References feature of TypeScript. Additionally, unless there is a requirement to provide type information for plain JS code, typeRoots are unnecessary as the type information should already exist in the "outDir" of P1.

Using TypeScript absolute imports from another project for standard TypeScript files and declarations at a global scope

Answer №1

Similar questions

The module declaration is triggering a lint error that reads "Unexpected token, expecting '{'"

The process of invoking another component's method in Angular 2

What is the best way to resolve the "unknown" type using AxiosError?

Validating nested objects in YUP with the potential for zero or multiple properties present

Testing the React context value with React testing library- accessing the context value before the render() function is executed

How can we efficiently load paginated data from a database while still implementing pagination using Angular Material?

What could be causing NgModel to fail with mat-checkbox and radio buttons in Angular?

Jest is unable to handle ESM local imports during resolution

Issue with ng2-charts not rendering properly on the client side when utilized in Angular version 2.0.0-beta-17

TS - deduce the specific type of a key value without receiving a union type

Accessing environment-based constants in TypeScript beyond the scope of Cypress.env()Is there a way to gain access to environment-specific constants

Change icons in Ionic 5 when selecting a tab

Where can I locate htmlWebpackPlugin.options.title in a Vue CLI 3 project or how can I configure it?

Using p5.js with TypeScript and Webpack is not supported

Is there a workaround for utilizing reducer dispatch outside of a React component without relying on the store?

Trying out the results of angular services

Tips for implementing react-hook-form in an Ionic Modal?

Uh-oh! A circular dependency has been detected in the Dependency Injection for UserService. Let's untangle this web and fix the issue!

Choose the AuthGuard category in real-time

Arrow functions do not function properly with Typescript decorators