how to create angular library in version 8 of components which can use in future angular versions like 12, 13, 14 etc?

Question

Is any technique/ approach or entire new setup required for this, please help me understand this. angular element is the only one solution or any other approach we can use?

Answer 1

My thoughts:

Angular Elements (aka WebComponents) you have already mentioned. The advantage is that they will always use their own dependencies (that means they stick to the old versions, even if your main application already uses much newer ones). The downside is that your application now have to load the old AND the new versions. And, even worse, if you do not take precautions, EACH WebComponent will load its dependencies, even if multiple WebComponents use the identical ones.

If you do not use WebComponents, the problem is, that your component code is dependent on other libraries which are defined in your main app. Whenever those libraries provide a new version, which contains a breaking change, then it could happen that your existing code does not work anymore until you adept it.

There is no perfect way around that, at least i do not know one.

But with a few measures, you can reduce the impact somehow.

1. Use less external dependencies.
   => If your component is using 10 external libraries, then its much more likely that one of them will have a breaking change and you have to adept your code, then if you only use 1-2 external libs
2. Try to stick to external dependencies which at least try to be backward compatible.
   => Easier said then done. It is a very restricting requirement, therefore very few provider really try to stay always backward compatible. As an alternativ i would at least check that all your external dependencies are using semantic versioning AND have a good documentation of breaking changes (and in the best case also migration guides). Then you can at least KNOW when you have to check your code and how you could adept it.
3. Do not use external dependencies all over your code. Instead wrap them and only use the wrapper.
   => If there is a breaking change, this increases the chance that you only have to adept the wrapper and not all those spreaded usages in your code.
4. If you really want to be on the save side, write unit tests which test the library APIs that you are using. That may be quite some work, but the advantage is, that you will be automatically informed when a version change will breaking your application. While your "normal" automated tests may tell you that something in your app is broken, those API tests will tell you the reason. Which makes debugging a breeze. But you really have to think about if the additional effort of unit testing APIs of your dependencies is worth the effort.

Long story short:
Use WebComponents, never have to worry about version changes, but live with the performance drain (and that you may miss security updates).

Or apply some coding rules which increases the effort (at least when creating functionalities), you will still have to update your component library from time to time, but at least updating it gets much easier.

IF your component library is used by a lot of projects. Then i would prefere the WebComponent approach. Because those projects will quite likely use different versions and if you do not use the WebComponent encapsulation your component library then would have to support all of those versions. And you have to provide and maintain multiple versions of your lib.
If your lib is only used by one or just a few projects. And you have a good control over them, so that they can all adept to your new lib version. Then i think you can also run without the WebComponent solution and stick to the above mentioned coding practices.