Hi,
After upgrading our project from ABP 9.3.7 to ABP 10.1.1, we regenerated the Angular proxies and encountered a TypeScript compilation error.
Environment
ABP Framework: 10.1.1
Angular: 21.2.3
ABP CLI: 2.2.1
Issue
After generating the proxy models, the Angular build fails with the following error:
TS2430: Interface 'GetIdentityUsersInput' incorrectly extends interface 'ExtensiblePagedAndSortedResultRequestDto'.
Types of property 'id' are incompatible.
Type 'string | null | undefined' is not assignable to type 'string | undefined'.
Type 'null' is not assignable to type 'string | undefined'. [plugin angular-compiler]
src/app/proxy/volo/abp/identity/models.ts:39:17
39 │ export interface GetIdentityUsersInput extends ExtensiblePagedAndSortedResultRequestDto
The generated proxy interface is:
export interface GetIdentityUsersInput extends ExtensiblePagedAndSortedResultRequestDto {
filter?: string;
roleId?: string | null;
organizationUnitId?: string | null;
id?: string | null;
userName?: string;
}
However, ExtensiblePagedAndSortedResultRequestDto defines the id property as:
id?: string;
Because of this, TypeScript reports that the child interface is widening the type (string | null), which is not compatible with the base interface (string).
Thanks.
14 Answer(s)
-
0
Hello,
Thank you for providing additional details about the issue. It may be related to a mismatched TypeScript version or the configuration in your
tsconfig. Could you please share your TypeScript version and the relevanttsconfigsettings if possible?Thank you for your cooperation.
-
0
Hi,
I don't think this is related to TypeScript configuration but rather to the changes made in proxy class generation logic in ABP 10.x as described in https://abp.io/support/questions/10400/ABP-10-Angular-proxy-required-C-fields-generated-as-optional-in-TypeScript
Id field in GetIdentityUsersInput in .NET (Volo.Abp.Identity.Pro.Application.Contracts) is defined as: public Guid? Id
However, it TypeScript, it is defined in a base class ExtensibleEntityDto (abp-ng.core.d.ts) as id?: TKey. This does not correspond to .NET definition where Id field is not present on same DTO but also it does not correspond to changes made to proxy class generation.
So when GetIdentityUsersInput interface is generated using proxy class generation, it will generate Id field as id?: string | null;. Since it is inheriting from ExtensibleEntityDto, it will fail to compile.
I can see two different issues:
- DTOs between .NET and Angular are not the same (in ABP.IO packages) - this is what is causing the issue described above
- DTOs in Angular are not following the pattern used by proxy generator (in ABP.IO packages) - this is what might be causing issues but not a direct cause of the above.
Thanks, Pavel
-
0
I don’t think this is related to the TypeScript configuration, but rather to the changes made in the proxy class generation logic in ABP 10.x, as described here: https://abp.io/support/questions/10400/ABP-10-Angular-proxy-required-C-fields-generated-as-optional-in-TypeScript
I asked because configuration mismatches can sometimes lead to issues like this.
As mentioned, this update was made deliberately, as explained in the issue. Could you also clarify whether you are using the npm-installed version of the packages or if you embedded the project’s source code directly?
-
0
ok, sure. Below is our tsconfig.json file:
/* To learn more about this file see: https://angular.io/config/tsconfig. */ { "compileOnSave": false, "compilerOptions": { "baseUrl": "./", "outDir": "./dist/out-tsc", "strict": true, "noImplicitOverride": true, "noPropertyAccessFromIndexSignature": true, "noImplicitReturns": true, "noFallthroughCasesInSwitch": true, "skipLibCheck": true, "isolatedModules": true, "esModuleInterop": true, "experimentalDecorators": true, "moduleResolution": "bundler", "importHelpers": true, "target": "ES2022", "module": "ES2022", //"sourceMap": true, "declaration": false, "lib": ["ES2022", "dom", "esnext.disposable"], "paths": {}, "useDefineForClassFields": false }, "angularCompilerOptions": { "enableI18nLegacyMessageIdFormat": false, "strictInjectionParameters": true, "strictInputAccessModifiers": true, "strictTemplates": true } }
Our TypeScript version 5.9.3 and we use npm-installed version of the packages. We should be on the latest versions as of last Wednesday.
Thanks, Pavel
-
0
Hello again,
Thank you for sharing the details. The issue is caused by these two TypeScript options:
strictandisolatedModules.If you do not need them for a specific reason, I recommend disabling them to resolve the error.
-
0
Hi,
I don't really agree that the issue is caused by the TypeScript options. These options are used for strict type checking in our code and we do want to keep them. These flags will only make the describe issue to transpire.
The issue is really in ABP.IO npm packages that do not have types defined correctly. Would it be possible to fix those so they correspond to server side DTOs and current logic for proxy class generation?
Thanks, Pavel
-
0
I agree that the
strictconfiguration will not produce errors when using embedded proxies instead of manually connected ones. However, theisolatedModulessetting can still cause such errors, as the framework is not intentionally designed to meet these requirements.
-
0
Hi,
our issue is not with isolatedModules configuration in TypeScript so perhaps we should concentrate on the original issue. Changing isolatedModules configuration has no effect on our issue.
The issue is really in ABP.IO npm packages that do not have types defined correctly. Would it be possible to fix those so they correspond to server side DTOs and current logic for proxy class generation? I would consider this to be a bug in the framework.
Thanks, Pavel
-
0
Hello again,
our issue is not with isolatedModules configuration in TypeScript so perhaps we should concentrate on the original issue. Changing isolatedModules configuration has no effect on our issue.
I may have misunderstood the problem reproduction steps. When I disable these configurations, the issue no longer occurs. However, if you can share a minimal reproducible example, I would be happy to take another look and assist further. Here is my e-mail address: sumeyye.kurtulus@volosoft.com
Thank you for your cooperation once more.
-
0
Hi,
you can easily test it by creating a blank application and adding a single AppService inheriting from IdentityUserAppService. No need to override anything. See the service below:
using System; using System.Linq; using System.Threading.Tasks;
using Microsoft.AspNetCore.Identity; using Microsoft.Extensions.Options;
using Volo.Abp.Application.Dtos; using Volo.Abp.Authorization.Permissions; using Volo.Abp.Caching; using Volo.Abp.EventBus.Distributed; using Volo.Abp.Identity; using Volo.Abp.Threading;
namespace Test.Identity;
public class MyIdentityUserAppService : IdentityUserAppService { public MyIdentityUserAppService( IdentityUserManager userManager, IIdentityUserRepository userRepository, IIdentityRoleRepository roleRepository, IOrganizationUnitRepository organizationUnitRepository, IIdentityClaimTypeRepository claimTypeRepository, IdentityProTwoFactorManager twoFactorManager, IOptions<IdentityOptions> identityOptions, IDistributedEventBus eventBus, IOptions<AbpIdentityOptions> abpIdentityOptions, IPermissionChecker permissionChecker, IDistributedCache<IdentityUserDownloadTokenCacheItem, string> userDownloadTokenCache, IDistributedCache<ImportInvalidUsersCacheItem, string> importInvalidUsersCache, IdentitySessionManager sessionManager, IdentityUserTwoFactorChecker userTwoFactorChecker, ICancellationTokenProvider cancellationTokenProvider) : base( userManager, userRepository, roleRepository, organizationUnitRepository, claimTypeRepository, twoFactorManager, identityOptions, eventBus, abpIdentityOptions, permissionChecker, userDownloadTokenCache, importInvalidUsersCache, sessionManager, userTwoFactorChecker, cancellationTokenProvider) { } }
Once you have this, compile it and generate client proxies in Angular. If you then set script flag to true (to ensure TypeScript properly checks data types), you will get an error described in the original post.
My comment from 2 days ago then describes why it is happening and the differences between base DTOs in Angular packages and in .NET. This was not an issue in ABP.IO 9.3.7.
Thanks, Pavel
-
0
As mentioned at the beginning, this update was implemented intentionally to satisfy other requirements. Therefore, this part does not require a refactor or fix.
As a result, the decision on your side is whether to continue using the TypeScript configurations “strict” and “isolatedModules,” or to switch to a different version of schematics. We do not typically make such recommendations; however, version
9.3.xof schematics has worked successfully in my case.If needed, I can also share the project I used to reproduce the issue.
Thank you for your cooperation.
-
0
Hi,
I am sorry, but I am not really happy with your answer. We are a paying customer and as such I would expect similar issues to be considered for fixing rather than being advised to disable type checking. Disabling strict type checking is only hiding the issue but not resolving it!
You you are saying that it is correct that DTOs in Angular and .NET are different and they are not going to get fixed? Have a look at definitions of ExtensibleLimitedResultRequestDto both .NET and Angular side. Is that really such a big issue to change the following definition in abp-ng.core.d.ts:
declare class ExtensibleEntityDto<TKey = string> extends ExtensibleObject { id?: TKey; constructor(initialValues?: Partial<ExtensibleEntityDto<TKey>>); }
so id column is defined as id?: TKey | null; to correspond to the way your proxy generator has been updated to in ABP 10.x?
Or to update the following definition in the same file so ExtensibleLimitedResultRequestDto does not have id column at all same way it is in .NET? I still consider this to be an issue as having different columns in DTOs server and client side is not correct, no matter what other purpose it has been done for!
declare class ExtensibleLimitedResultRequestDto extends ExtensibleEntityDto { maxResultCount: number; constructor(initialValues?: Partial<ExtensibleLimitedResultRequestDto>); }
This really prevents us from extending pretty much any ABP.IO base class as the is no way to direct proxy generator to ignore some methods and once we extend IdentityAppService, it will generate models for all existing methods and then we will get a compilation error.
Thanks, Pavel
-
0
After reviewing this with my colleague, we have decided to implement a fix that addresses this case. In short,
ExtensibleLimitedResultRequestDtowill be updated to extendExtensibleObjectinstead ofExtensibleEntityDto.Until this fix is released, I can suggest a temporary workaround on the generated proxy. You can either remove the unnecessary null checks on the properties causing the error, or remove those properties altogether.
You can follow the updates here: https://github.com/abpframework/abp/issues/25115 https://github.com/abpframework/abp/releases https://abp.io/docs/latest/release-info/release-notes
I will also process a refund for this ticket. Thank you for your cooperation.
-
0
Hi, that's a great news, that is exactly what I was hoping for. Thank you. We are currently fixing generated proxy manually but as you can imagine, it is quite annoying especially when working on a project with a group of developers where we re-generate proxies frequently.
Thanks for the update.
Pavel
