-
Notifications
You must be signed in to change notification settings - Fork 826
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
fix: align dependency versions #3847
fix: align dependency versions #3847
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3847 +/- ##
==========================================
- Coverage 92.49% 91.34% -1.16%
==========================================
Files 222 120 -102
Lines 5610 2587 -3023
Branches 1077 543 -534
==========================================
- Hits 5189 2363 -2826
+ Misses 421 224 -197 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you intend to change the ^
dependencies to pinned versions?
Yes, just like most packages. |
31a6b5a
to
a2272e4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks. I'm not entirely sure why some versions were not pinned in the first place 🤔
At least in the past the strategy was to pin only dependencies from the same lerna project as these dependencies are automatically updated on each release. On the other hand dev-dependencies were pinned to reduce the risk of autobreaking the build and we were not able to use lock files. After this PR we seem to have some pinned deps (e.g. protobufjs, semver, require-in-the-middle) and some not pinned (e.g. @grpc/grpc-js). Pinning likely results in duplication of packages for end users because renovate bot tends to fail in this repo and we are slow in updating. in special for bigger packages like @grpc/grpc-js or protobufjs this is usually not nice. I think we need a reasoning/guideline regarding this. |
You are right. I am not sure why some dependencies are pinned and others are not. But at least we should keep the versions of the same package the same. (we have |
Ah, that makes sense.
I agree, we should have a guideline for this, I'll look into drafting one up. I think it makes sense to unpin larger packages for the reason you stated.
Agreed. @llc1123 would you mind unpinning |
It looks I made a mistake while searching for dependencies on Intuitively I'd say to
|
I've updated the code. I unpinned all dependencies except ones in the lerna project. |
experimental/packages/opentelemetry-instrumentation/package.json
Outdated
Show resolved
Hide resolved
fb3b520
to
be48adf
Compare
@Flarna What do you think of this version? |
Co-authored-by: Marc Pichler <marc.pichler@dynatrace.com>
Short description of the changes
Fixed several version mismatches of dependencies.
I will try to refactor
web-opentelemetry-example
and get rid ofwebpack@4
(which is incompatible with node 17+) in another PR.Type of change