Angular component

[GuiEpi]

Hello everyone!

I created the Angular component for this project (https://github.com/jackocnr/intl-tel-input/tree/master/angular). I'm not an Angular expert, so I have a few questions about my implementation and would appreciate feedback:

1. Component vs Directive Architecture

Wouldn't it have been better to use a @Directive rather than a @Component? This would allow users to have all the native input events directly available. The current applyInputProps function is not very optimal and could be removed with a directive approach.

@Directive({
  selector: '[intlTelInput]',
  standalone: true,
  providers: [
    {
      provide: NG_VALUE_ACCESSOR,
      useExisting: forwardRef(() => IntlTelInputDirective),
      multi: true
    },
    {
      provide: NG_VALIDATORS,
      useExisting: forwardRef(() => IntlTelInputDirective),
      multi: true
    }
  ],
  host: {
    '(input)': 'handleInput()',
    '(blur)': 'handleBlur()'
  }
})

I've already converted the @Component to a @Directive version, but I'm unsure which approach is best. Making this change would be pretty straightforward if needed.

2. Angular Version Compatibility

I used the traditional @Input/@Output syntax rather than modern Angular signal-based approaches. This means I could potentially lower the minimum required Angular version to 17 or 18. Would this be beneficial for broader compatibility?

3. Custom Build Process

I implemented a custom build using ngc + esbuild to preserve Angular metadata (see PR #2056). While my tests show no issues, I'm wondering if this approach could cause problems with Angular applications or if there are potential issues I'm overlooking.

Any insights or suggestions for improvement would be greatly appreciated!

Thanks for your feedback.

[jackocnr]

Tagging Angular people who might be interested @HelloooJoe @MarcoGlauser @stefann4 @javiermarinros @alouarrani @mtarregh @sandeep537 @juvegitau @datasage @mpalourdio

[mpalourdio]

1. Components are, IMO, fire and forget, and even if more verbose, expose an explicit "API" that are more obvious to be caught by IDE and end consumers.
2. I would go to signals, that's a no brainer for me. Keeping BC for a framework that delivers a major version every 6 months will make you suffer more than necessary.
3. Use ng-packagr, it does absolutely all that you need. Custom build process means custom code, and, per se, custom bugs.

[GuiEpi]

First of all, thank you for your feedback.

1. Ok, I'll stick with the Component approach.

2. I will migrate to signals fairly quickly in this case.

3. I'm open to using ng-packagr. However, I have some questions about the ng-packagr approach:

   a) One challenge I see with ng-packagr is handling the environment variable transformation (process.env.VERSION). My current esbuild setup handles this cleanly with the define option. How would ng-packagr handle this scenario?

   b) How would ng-packagr integrate with the existing multi-framework build system (React, Vue, Angular all in one repo)? ng-packagr expects a traditional Angular library setup with a public_api.ts entry file, but my components are integrated into the existing structure and directly target component files (angular.ts, angularWithUtils.ts) without requiring source reorganization.

If these concerns can be addressed, I'm happy to migrate to ng-packagr.

[mpalourdio]

3. I did not look at the build process, so I can't say for sure. ng-packagr will work well if you deploy the angular component as standalone on npmjs, with its own package.json and so on. Not sure how you would integrate this here without having a serious look at the code, sorry