Allow for multiple versions of Forge components to 'live' inside the same environment.



ForgeComponent1 consumes ForgeComponentX version 1.0

ForgeComponent2 consumes ForgeComponentX latest version 2.0

Version 2.0 of ForgeComponentX has breaking changes (for example, a public server action is no longer available as it was in version 1.0)

Now I have the following options:

  1. depend and wait on team for ForceComponent1 to make there component to use version2 of ForgeComponentX
  2. clone ForgeComponent1 and do the change myself.

My preference is to minimize the need to clone forge component, for obvious reasons. But I also have project targets that I have to meet.  Both options will cost time (either I wait on the development team) or I have to spent time myself on cloning and fixing the issue myself.


Allow multiple versions of Forge components to 'live' inside the same environment.

I come from a .NET background, and the above situation has long time been tackled by Microsoft. Packages in .net are part of your solution not of the environment.

Low code should make live easier for a developer, not create old problems that I really forgot about.

Created on 8 Feb
Comments (3)

Changed the category to References

Hi Daniël!

I think the need to have "multiple versions of Forge components inside the same environment" is an exception situation, although the idea makes sense.

Forge components normally do not depend on many other components, or if they do, those dependencies are system components like "Silk UI Web", "OutSystems UI Mobile", etc.

As an example, the Forge components where you are a contributor, they only depend on system components (except for the Sleep, which is very simple and basically a "system component").

So, if you really have the need to have installed different versions of the same Forge component, I think that cloning is an acceptable solution.

--Tiago Bernardo

Hi Tiago,

Fair enough, it also helps if forge component teams keep update their components to use recent versions of dependent components. I just got some flashbacks from dll hell times with .net, and that triggered me to create the idea. 

But you are right, it are exception situations.