New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KT-45789 Transitive npm dependencies #4888
Conversation
I am wondering what situation will occur, if direct and transitive dependency will be the same but different versions (with different cases when version ranges are compatible and incompatible). |
Yeah, I wondered about that too. Shall I implement some form of resolution to guarantee uniqueness and implicity select the highest version? Alternatively I could fail the build and report such occurences. Then the consumer would need to specify desired dependencies for clashes in direct npm dependencies at the sourceSet level |
In any case, I think we can both agree that direct dependencies should take priority? |
To be clear, my first point was in context of version clashes between two transitive dependency sources, not between transitive and direct. |
I think that direct should take priority (possibly with warning). As for operations with NPM versions, you can take a look on |
How's this:
|
Basically it is ok. But what if there will be versions like |
I think it's fine to ignore version modifiers for resolution as long as a warning is printed. If there are any issues end user can just declare a direct dependency |
Ok, as far as it is not widely announced. It looks good to me |
Do you think it should be toggled behind some feature flag? Or is it ok to just add it on top of existing workflow? |
I think it is ok without feature flag, because it affects mainly experimental |
Ready for another look now. |
A gentle reminder to have a look at this before I go ahead solving new merge conflicts :) |
I’ll take a look, will try tomorrow |
LGTM, I'll run it on CI |
Merged in 3e6253c |
Closes KT-45789