-
Notifications
You must be signed in to change notification settings - Fork 533
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
feat(instr-tedious): added support for v18 #2267
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2267 +/- ##
==========================================
- Coverage 90.97% 90.29% -0.69%
==========================================
Files 146 147 +1
Lines 7492 7242 -250
Branches 1502 1499 -3
==========================================
- Hits 6816 6539 -277
- Misses 676 703 +27
|
1696fa7
to
ed80e2d
Compare
@@ -47,20 +47,23 @@ | |||
"@opentelemetry/api": "^1.3.0" | |||
}, | |||
"devDependencies": { | |||
"@typescript-eslint/eslint-plugin": "6.21.0", | |||
"@typescript-eslint/parser": "6.21.0", | |||
"eslint": "8.9.0", |
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.
8.9.0 includes support for es2022.
We do not want to go higher as part of this PR, because it raises more errors e.g. --ext
is not defined. Bumping eslint to the latest can be part of a different PR.
@@ -47,20 +47,23 @@ | |||
"@opentelemetry/api": "^1.3.0" | |||
}, | |||
"devDependencies": { | |||
"@typescript-eslint/eslint-plugin": "6.21.0", |
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.
"test-all-versions": "6.1.0", | ||
"ts-mocha": "10.0.0", | ||
"typescript": "4.4.4" | ||
"ts-node": "^10.9.2", |
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.
Replaced ts-mocha. Was no longer working.
ConnectionConfig as ConnectionConfigLegacy, | ||
// eslint-disable-next-line @typescript-eslint/ban-ts-comment | ||
// @ts-ignore | ||
ConnectionConfiguration as ConnectionConfigNew, |
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.
I know using ts-ignore is not ideal. I was not able to find a better & easier solution. And I am not very familiar with TS.
Possible long-term:
- write tests in TS
- run tests in JS
- requirement: remove the test build folder from the git ignore list
- needs a follow up ticket IMO
@@ -31,6 +31,8 @@ module.exports = { | |||
rules: { | |||
"@typescript-eslint/no-floating-promises": "error", | |||
"@typescript-eslint/no-this-alias": "off", | |||
'@typescript-eslint/no-explicit-any': "warn", | |||
'@typescript-eslint/no-unused-vars': "warn", |
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.
typescript-eslint/typescript-eslint@5346b5b
We need to add these because of using typescript-eslint/typescript-eslint in this pkg.
I know they need to belong to the eslint package file, but I thought this is fine as well and easier, because it was a warning before anyway.
RFR There were lots of challenges in this PR. I have tried my best to give context for the changes. |
@open-telemetry/javascript-approvers Requesting a review |
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.
Thank you for working on adding the support for this new version.
Wrote few comments / concerns
@@ -78,7 +78,7 @@ export class TediousInstrumentation extends InstrumentationBase { | |||
return [ | |||
new InstrumentationNodeModuleDefinition( | |||
TediousInstrumentation.COMPONENT, | |||
['>=1.11.0 <18'], | |||
['>=1.11.0 <19'], |
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.
please also update the supported version range in the README of the instrumentation.
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.
Will do
"ts-mocha": "10.0.0", | ||
"typescript": "4.4.4" | ||
"ts-node": "^10.9.2", | ||
"typescript": "5.3.3" |
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.
I think this might be considered a break change which we try to avoid. @dyladan is it safe to apply?
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.
Why is that a breaking change? Its a dev dependency.
Please respect the reasoning in the PR description. We have to update ts
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.
I am not familiar with the exact details, but I remember discussions that if we update typescript version for the package, exiting users of the instrumentation with typescript 4 might have their transpiration broken.
@open-telemetry/javascript-maintainers can someone please help and supply guidance on the safe way to do that?
"@opentelemetry/api": "^1.3.0", | ||
"@opentelemetry/context-async-hooks": "^1.8.0", | ||
"@opentelemetry/contrib-test-utils": "^0.40.0", | ||
"@opentelemetry/sdk-trace-base": "^1.8.0", | ||
"@types/mocha": "7.0.2", | ||
"@types/node": "18.6.5", | ||
"mocha": "7.2.0", | ||
"mocha": "^10.4.0", |
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.
is it needed for this PR to work?
we aim to align the entire repo to use the same common dependencies, so this should ideally be bumped as a dedicated PR that does that for all packages in the repo
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.
I understand. As far as I remember I had to update mocha because I had to replace mocha-ts with ts-node as described.
But I can double check if you want to 👌
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.
Thank you, @kirrg001.
I reviewed a few other instrumentations to see how they handle tests. Based on their dependencies, I believe our current setup should work without needing to bump the shared monorepo dependency versions unless absolutely necessary.
However, I do support the idea of opening a dedicated PR to update some of the dependencies across the repository. If you have the time and would like to contribute to this effort, it would be greatly appreciated.
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.
I will try to downgrade mocha to v7 again and let you know :)
// eslint-disable-next-line @typescript-eslint/ban-ts-comment | ||
// @ts-ignore | ||
ConnectionConfiguration as ConnectionConfigNew, | ||
} from 'tedious'; |
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.
Since we have both types from tedious
and from the still existing @types/tedious
dependency, is this import able to join them both?
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.
I am not aware of any other solution. Please suggest a working alternative approach :)
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.
I was actually wondering if you know how it works. Since it's test code, i don't think we need to worry and the current implementation is fine with me, but curious how typescript handles situation where the types exists twice in node_modules
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.
If the tests are running, depending on the current installed tedious version (types are either in tedious or in @types), the code imports whats available.
I feel like TS was not designed to fulfill such a use case.
@open-telemetry/javascript-approvers Requesting a review |
@open-telemetry/javascript-maintainers I would love to merge this. Requesting further feedback. |
Hi. I took a look and tried to work through the same issues. I put up a branch for comparison:
on skipLibCheck
It would fail with:
The alternative would be to update the tsconfig "target" to "es2022". That might have an impact on the shipping code for instr-tedious, so I thought that should be avoided for now, at least. optionsPlease let me know which you would prefer:
|
@trentm Thanks so much for taking the time to review this.
This option sounds like the easiest. I'd suggest that you are opening your PR and I'll close mine :) |
Closing in favor of #2381 |
closes #2266
Why?
Problems:
Possible follow up tickets: