You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Various host languages have varying degrees of support for co-existence of multiple versions of the same module within their runtime closure. For example, node/npm simply allows that (since the runtime closure is a directory tree), Java supports it only with certain class loaders, etc.
The questions are:
Should the jsii-runtime support it (at the moment, it intentionally blocks this from happening)
What happens in environments where this is not supported? Do we have a way to help users resolve these conflicts?
The text was updated successfully, but these errors were encountered:
I think the compiler has opportunities to catch this problem, too. If jsii-runtime will not allow something, the compiler shouldn't allow it either (but they must still both validate, since what is built against may differ from what is run against).
We determined that the best approach for jsii would be to enforce that all dependencies are always specified as "peer dependencies". This forbids closures from including more than a single version of a certain module and essentially levels the playing field amongst jsii languages.
Various host languages have varying degrees of support for co-existence of multiple versions of the same module within their runtime closure. For example, node/npm simply allows that (since the runtime closure is a directory tree), Java supports it only with certain class loaders, etc.
The questions are:
The text was updated successfully, but these errors were encountered: