Add support for angular 13

[rbalet]

Would be nice to have it support angular 13.

cheers

[AlexMiniApps]

@rbalet ok I will check

[1andy11]

Hello,
we would like to use the component in our angular 13 app., which is not possible.
The problem we are faceing is "(0 , tslib__WEBPACK_IMPORTED_MODULE_1__.__awaiter) is not a function" when something is written to field.

Regards.

[AlexMiniApps]

@1andy11 The compiled component version from NPM repo is working as intended in the angular v 13. I have created test project here:
https://stackblitz.com/edit/angular-ivy-yw6tk6?file=src%2Fapp%2Fapp.component.ts

Also I have created local blank angular app with the 13 version and also did not see any issues. If you would like I can send you sources which I have used to test the component on the Angular v 13

[rbalet]

@AlexMiniApps I can do the migration if you're willing to merging it. Should I start with it?

Btw, I'm confirming using angular 13 with ionic and it work smoothly

[AlexMiniApps]

@rbalet

I can do the migration if you're willing to merging it. Should I start with it?

Thank you but no :) It is quite simple procedure, but I need to perform some checks after that. I will do it.
How urgent is the component updating to v13 for you @rbalet ?

[rbalet]

@AlexMiniApps This is much more a nice to have than a need for now. But not having ivy enable is a problem for the overall optimization of the code & will be a problem in the not to distant future.

So for the small effort it cost, this would be a huge step forward.

Thx for you work!

[AlexMiniApps]

@rbalet I understand you. ok

[1andy11]

@AlexMiniApps The problem was in my configuration of the project. It is strange but specifying "paths" in tsconfig.json break it. When I removed all paths it was working.

Thanks.

[rbalet]

@AlexMiniApps I think you can close this issue ?

[AlexMiniApps]

@rbalet nope :) I am working on the release with the enabled ivy, but with the backward compatibility of the prev angular versions. I will close the issue by myself.

[rbalet]

@AlexMiniApps I think you should put that much effort on backward compatibility.

You just mention on the README and it should be enough.

My reasoning being that

1. I'm not sur this is possible as Angular just ditch older version.
2. People that does not have Angular v12 certainly are happy enough with the version you gave them already
3. Faster implantation of other feature which more people are waiting for :)

[AlexMiniApps]

@rbalet You're right that Angular seems does not have the backward compatibility. I'm thinking about to split the npm package into two versions of the lib - with and without ivy support respectively.

[rbalet]

@AlexMiniApps As you think it good.

But people whom are using it in ionic will have to update to the latest angular, if they wish it to be working on latest smartphone os.

So splitting it won't be required for ionic users.

For angular one, I do think they won't update your library even if you add new feature since they didn't took the time to migrate to ivy (which is already 1 Years old).

Let me know if I can be of any help :)

[wassim-k]

@AlexMiniApps any update on this, Angular 16 removed ngcc support and this library is no longer usable.

[AlexMiniApps]

@wassim-k I will check it.

[lousley]

Any updates for angular 16 verson?

[AlexMiniApps]

Yep. I am working on this, when have a free time.

[AlexMiniApps]

@rbalet Thank you for the PR. I am thinking about how to keep non ivy version and ivy together (maybe in the separate packages). I do not want to lose the support of the older Angular versions.

[rbalet]

@AlexMiniApps Fact is, if you wish to keep the IVY version, you wont have the right to go with angular 15 and higher. (Since the compilation change). so people will slowly but surely drop your library for a more modern one.

But I would say, you have the following two options

1. Split libraries

Create a second ngx-angular-code-input library that deal with the latest version of angular.
In case you could create some shared used logic, but this isn't worth it for the size of the project

2. Populate a README

What most libraries are doing,
put in the readme a list of which version to download for which angular

This would be an example

Angular	@ngx-translate/core	ngx-translate-multi-http-loader
16	16.x+	16.x+
15	15.x+	9.x+
14	14.x+	8.x+
13	14.x+	7.x+
6	10.x+	1.x+

Let me know what you wish to do, I'm ready to help you on both case

[AlexMiniApps]

@rbalet Thank you for the advice. I am thinking about the splitting. I am planning to keep the consolidate code base and two build systems for different Angular versions.

[AlexMiniApps]

Hello, guys I have published the package with the latest version of 2.0.0.
Breaking changes:
Enabled Ivy in the compiled library
The minimum supported version of Angular is set to 16

@rbalet Thank you for help.