One key word that often comes up in this department is "code sharing".
The NativeScript TSC's 5 fundamental lessons about good code sharing
If you can share your code easily with other paradigms, other disciplines, other runtimes even, then you have a good code sharing approach that will continue to provide you and your team joy. No developer or team willingly gets into code sharing hoping to find themselves in a corner later. You always want to share now to more easily maintain and scale the code later.
A good code sharing approach should fit naturally in with well supported community standards and not require any extra build tooling just for the sharability to support itself. It should, in other words, stand firmly on it's own in scope of the language it is written in.
A good code sharing approach should not have to introduce new file extensions purely for sake of sharability (outside of those naturally supported by the framework) to deal with. All team's organize code by folders naturally and the same should be matched with good code sharing approaches avoiding new file extensions and concepts that go beyond general code organization.
A good code sharing approach should clearly identify deployment/distribution lines as well as distinct platform separation allowing various shared code segments to have clear designated deployment targets allowing teams to control their own sophisticated build pipelines as they desire. Further the shared code should live within a thoughtful organizational structure that supports the ability to scale and adapt to future needs aside from the deployment targets that use the shared code.
Framework's are often "domain specific in nature". Programming languages are often the opposite or at least more broadly applicable to a wider set of domain problems. A good code sharing approach centers itself around the programming language and not the framework.
If a "code sharing solution" is maintained by a framework that can often mean there are inherent biases that interlock it's "sharable nature" with the framework, even if not intentional, it is somewhat inevitable. This breaks the first rule of a good code sharing approach.