zeldx created 3 months ago

Angular Compiler Error (TS2307) after Downloading Account.Pro Source Code (v10.4.1)

Message

Hi ABP Support Team,

I am facing a blocker with the Angular application in my ABP Commercial project (v10.4.1) after downloading the source code for the Volo.Abp.Account.Pro module.

🚨 The Issue

When running the Angular compiler (npm start or ng build), it fails with the following error inside the newly downloaded module projects:

X [ERROR] TS2307: Cannot find module '@abp/ng.core' or its corresponding type declarations. [plugin angular-compiler]

  ../modules/Volo.Abp.Account.Pro/angular/projects/account/admin/config/src/account-admin-config.module.ts:1:27:
    1 │ import { CoreModule } from '@abp/ng.core';

📂 Context & Configuration

ABP Version

10.4.1 (Commercial)

Current Situation

I have other local modules (e.g., a custom finance module) under the ../modules/ directory, and they are working completely fine without any compilation or path mapping issues.

Module Structure

The downloaded Volo.Abp.Account.Pro module contains a projects folder with account and account.core. Each sub-project contains its own isolated tsconfig.lib.json which has:

{
  "types": []
}

and extends from a local base configuration.

Main Application `tsconfig.json`

{
  "compileOnSave": false,
  "compilerOptions": {
    "baseUrl": "./",
    "outDir": "./dist/out-tsc",
    "sourceMap": true,
    "declaration": false,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "moduleResolution": "bundler",
    "importHelpers": true,
    "skipLibCheck": true,
    "target": "ES2022",
    "module": "ES2022",
    "paths": {
      "@volo/abp.ng.account": [
        "../modules/Volo.Abp.Account.Pro/angular/projects/account/src/public-api.ts"
      ],
      "@volo/abp.ng.account/admin": [
        "../modules/Volo.Abp.Account.Pro/angular/projects/account/admin/src/public-api.ts"
      ],
      "@volo/abp.ng.account/public": [
        "../modules/Volo.Abp.Account.Pro/angular/projects/account/public/src/public-api.ts"
      ],
      "@volo/abp.ng.account/admin/config": [
        "../modules/Volo.Abp.Account.Pro/angular/projects/account/admin/config/src/public-api.ts"
      ],
      "@volo/abp.ng.account/public/config": [
        "../modules/Volo.Abp.Account.Pro/angular/projects/account/public/config/src/public-api.ts"
      ],
      "@volo/abp.ng.account/public/proxy": [
        "../modules/Volo.Abp.Account.Pro/angular/projects/account/public/proxy/src/public-api.ts"
      ],
      "@volo/abp.ng.account.core": [
        "../modules/Volo.Abp.Account.Pro/angular/projects/account.core/src/public-api.ts"
      ]
    },
    "useDefineForClassFields": false
  }
}

🛠️ What I Have Tried So Far

Explicitly mapped @abp/ng.core to target the root node_modules/@abp/ng.core inside the main tsconfig.json.
Cleared the .angular cache folder and rebuilt/reinstalled node_modules.
Modified the sub-project's internal tsconfig.json files to resolve paths manually.

However, the isolated compilation structure of Account Pro combined with "moduleResolution": "bundler" prevents it from tracking the global packages correctly.

❓ Question

Since this issue is isolated strictly to the Account Pro workspace architecture and does not affect my other source-code modules, could you please guide me on the official/correct way to resolve:

Path mappings for ABP Angular packages within downloaded commercial modules.
Required peer dependencies for Account Pro source-code projects.
Any additional workspace configuration needed when integrating the module into an existing Angular application.

Any guidance would be greatly appreciated.

Best regards,

Abdulsalm Alshuaibi

AI-Bot created 3 months ago

Support Team ABP Agent

The root cause is that the downloaded Account.Pro Angular libraries are being compiled as separate Angular library projects, and with Angular’s newer builder + "moduleResolution": "bundler", TypeScript can fail to resolve workspace-external dependencies (like @abp/ng.core) consistently when you reference module source via tsconfig.paths (e.g., pointing to ../modules/.../projects/.../src/public-api.ts). This frequently manifests as TS2307 (module not found) or related Angular compiler/type-check issues in modular development scenarios.
The officially working approach (and the one that avoids this entire class of resolution problems) is to not compile these module projects through tsconfig.paths pointing to their source. Instead, use one of these two approaches:

Option A (recommended): Consume the module UI as a built package (file:) instead of paths
1. Build the Account.Pro Angular libraries (the projects under ../modules/Volo.Abp.Account.Pro/angular/projects/...) so they produce their dist outputs.
2. In your main Angular app, reference them via package.json using file: (or a local tarball), rather than tsconfig.json paths into src/public-api.ts.
3. Remove (or at least stop using) the paths entries that point into ../modules/.../projects/.../src/....
This ensures there is one consistent dependency graph resolved from your main app’s node_modules.

Option B: Use symlinks so module projects resolve dependencies from the main app’s node_modules

If you must develop the module source “in place” inside the same repo, use a symlink strategy so the module library projects resolve the same physical @abp/* packages as the main app:
1. Avoid “redirecting” ABP framework packages with paths mappings (mapping @abp/ng.core manually is a common way to end up with inconsistent resolution).
2. Ensure the library projects under ../modules/.../angular/projects/... resolve dependencies from the main app’s angular/node_modules by symlinking (so they don’t behave like isolated workspaces with their own resolution roots).
About peer dependencies: Account.Pro Angular source projects expect the ABP Angular packages (like @abp/ng.core) to be available from the consuming app’s node_modules (same versions as your solution). When the module projects compile “isolated” and can’t see that node_modules consistently, you hit TS2307. Using Option A or B above fixes that by making dependency resolution consistent.
The "types": [] inside tsconfig.lib.json is not the core issue here; the problem is primarily the module resolution graph and the way the new builder handles paths + library compilation boundaries.

Sources:

https://abp.io/support/questions/10448
https://abp.io/docs/latest/framework/ui/angular/quick-start
https://abp.io/docs/10.0/framework/ui/angular/quick-start

This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

maliming created 3 months ago

Support Team Fullstack Developer

Hi,

The TS2307 happens because account-admin-config.module.ts resolves @abp/ng.core from inside ../modules/Volo.Abp.Account.Pro/angular/..., and there's no node_modules/@abp under that folder yet. The resolver walks up from there and never reaches your main app's node_modules.

The Angular template ships a script for exactly this case. Edit <your-app>/angular/scripts/symlink-config.ps1 and add the module's angular folder to $PackageDirectories:

$script:PackageDirectories = @(
    "../../modules/Volo.Abp.Account.Pro/angular"
)

Then from <your-app>/angular/scripts/, run:

pwsh ./setup-symlinks.ps1

You should see Linked @angular, Linked @abp, Linked @volo, Linked rxjs, Linked tslib printed, and the TS2307 will be gone. The default $PackagesToSymlink array already covers all the framework packages, so you only need to add the directory path.

One more thing: please remove the manual @abp/ng.core path mapping you added in your main tsconfig.json. After the symlinks are in place, Angular resolves @abp/ng.core from node_modules on its own — the manual mapping ends up competing with that and can lead to inconsistent resolution.

We'll fix this on our side so the path gets added and the symlinks get refreshed automatically when you Import a module or download a Pro module's source. It'll go out in the next ABP Studio release.

Thanks

Question details

ABP Version (vX.X.X)

Database Management System

Tiered (MVC) or Auth Server Separated (Angular)

Boost Your Development

ABP Live Training
Packages

See Trainings

The Official Guide

Mastering
ABP Framework

Learn More

Framework

Tools

Mobile

Startup Templates

UI

Modules

Angular Compiler Error (TS2307) after downloading Account.Pro source code (v10.4.1) #10736

Angular Compiler Error (TS2307) after Downloading Account.Pro Source Code (v10.4.1)

Message

🚨 The Issue

📂 Context & Configuration

ABP Version

Current Situation

Module Structure

Main Application `tsconfig.json`

🛠️ What I Have Tried So Far

❓ Question

2 Answer(s)

Option A (recommended): Consume the module UI as a built package (`file:`) instead of `paths`

Option B: Use symlinks so module projects resolve dependencies from the main app’s `node_modules`

ABP Live Training
Packages

Mastering
ABP Framework

Framework

Tools

Mobile

Startup Templates

UI

Modules

More

More

More

More

Angular Compiler Error (TS2307) after downloading Account.Pro source code (v10.4.1) #10736

Angular Compiler Error (TS2307) after Downloading Account.Pro Source Code (v10.4.1)

Message

🚨 The Issue

📂 Context & Configuration

ABP Version

Current Situation

Module Structure

Main Application tsconfig.json

🛠️ What I Have Tried So Far

❓ Question

2 Answer(s)

Option A (recommended): Consume the module UI as a built package (file:) instead of paths

Option B: Use symlinks so module projects resolve dependencies from the main app’s node_modules

ABP Live TrainingPackages

MasteringABP Framework

Main Application `tsconfig.json`

Option A (recommended): Consume the module UI as a built package (`file:`) instead of `paths`

Option B: Use symlinks so module projects resolve dependencies from the main app’s `node_modules`

ABP Live Training
Packages

Mastering
ABP Framework