moonbitlang
The dependence transmit in packages
Motivation
Consider this situation:
Packages A import package B and package B depend on C and some traits in B need the data type in C.
In now situation, packages B and A have to import the C so that the A can correctly use package B due to the dependence is not transmitted.
But there is a different case. A and B dependent on C but in different version and B didn't have the trait whose params or return val is type in C. If we transmit the dependence by the import chain, a conflict occur !
Detailed Description
According to the two cases above, I want to a function that can have two dependence type.
- private dependence the dependence will not be transmitted by the dependence chain.
- public dependence the dependence will be transmitted by the dependence chain.
Related Issues
Checklist
- [x] I have added all necessary details to make it easy for the maintainers to understand my request.
We do not have any plan to allow using transitive dependencies in the foreseeable future. This aligns with most of the other programming languages' behavior, and is easier to reason about during dependency solving. Allowing transitive dependencies' packages to be imported locally is bug-prone, since the direct dependency may change their dependency list without breaking the API.
If you are referring to "allow a package to re-export another dependency's symbol, and the downstream don't need to import the transitive dependency", that's something we're actively working on. The feature would still need some changes currently not present in moon to work, but it might be added in the future.
As of the "depending on different version" issue, that would require the compiler to recognize and differentiate between different (possibly incompatible) versions of the same package, which the moonc compiler currently does not. It has been brought up a couple of times, but we're not actively working on it yet.
Moved to moonbit-docs due to being a generic feature request instead of a moon-specific issue.
We currently use MVS to resolve the module (which I think is what you mean by package) and we follow the Semantic Versioning for the package versions. Thus if A and B both relies on C, it would resolve to a version that satisfies both A and B, as long as semver is respected.
If A and B relies on two versions that conflict with each other, also known as diamond dependency, it can't be simply solved by 'hiding' dependency.
