Skip to content
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

Closed
wants to merge 4 commits into from

Conversation

kirrg001
Copy link
Contributor

@kirrg001 kirrg001 commented Jun 7, 2024

closes #2266

Why?

  • Tedious v18 moved @types/tedious to their repository.
  • Tedious v18 uses Typescript v5 and es2022

Problems:

  • We need to use different typescript versions in the project. This creates conflicts and errors. I think because by default TS checks all TS Definitions in the root folder, which are not compatible against the TS v5.
  • We are using an outdated module ts-mocha. Won't build with newer typescript targets.
  • NPM Workspaces do not support nohoisting. Using nohoist makes it possible to move all @types/* and typescript dependencies into the packages and would avoid errors we are getting from typescript regarding root dependencies.
  • Eslint packages no longer compatibale. We had to update eslint packages for typescript too (for the package)
  • I had to use ts-ignore flag to import different type notations into the test. Not optimal, but easiest way. And using dynamic imports based on the tedious version did not work for me. And doing it like mongo is soo much code duplications. But I am also not an expert in TS. I am open to full working solutions.

Possible follow up tickets:

  • There is a root typescript dependency and every sub package has its own TS version. That doesn't make sense to me. Either one root ts version which every packages use and a package can override it on its own or the other way around.
  • Use tilde for dev dependencies to speed up installation (consistency change).
  • Replace ts-mocha with ts-node everywhere.
  • Update mocha to latest version everywhere.
  • Find a better way to avoid using ts-ignore.

Copy link

codecov bot commented Jun 7, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.29%. Comparing base (dfb2dff) to head (c007be8).
Report is 210 commits behind head on main.

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     
Files Coverage Δ
...ode/instrumentation-tedious/src/instrumentation.ts 92.13% <ø> (-0.34%) ⬇️

... and 57 files with indirect coverage changes

@kirrg001 kirrg001 force-pushed the tediousv18 branch 4 times, most recently from 1696fa7 to ed80e2d Compare June 10, 2024 10:09
@@ -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",
Copy link
Contributor Author

@kirrg001 kirrg001 Jun 12, 2024

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",
Copy link
Contributor Author

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",
Copy link
Contributor Author

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,
Copy link
Contributor Author

@kirrg001 kirrg001 Jun 12, 2024

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",
Copy link
Contributor Author

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.

@kirrg001 kirrg001 marked this pull request as ready for review June 12, 2024 13:54
@kirrg001 kirrg001 requested a review from a team June 12, 2024 13:54
@kirrg001
Copy link
Contributor Author

RFR

There were lots of challenges in this PR. I have tried my best to give context for the changes.

@kirrg001
Copy link
Contributor Author

@open-telemetry/javascript-approvers Requesting a review

Copy link
Member

@blumamir blumamir left a 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'],
Copy link
Member

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.

Copy link
Contributor Author

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"
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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",
Copy link
Member

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

Copy link
Contributor Author

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 👌

Copy link
Member

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.

Copy link
Contributor Author

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';
Copy link
Member

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?

Copy link
Contributor Author

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 :)

Copy link
Member

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

Copy link
Contributor Author

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.

@kirrg001
Copy link
Contributor Author

@open-telemetry/javascript-approvers Requesting a review

@kirrg001
Copy link
Contributor Author

@open-telemetry/javascript-maintainers I would love to merge this. Requesting further feedback.

@trentm
Copy link
Contributor

trentm commented Aug 10, 2024

Hi. I took a look and tried to work through the same issues. I put up a branch for comparison:
main...trentm:opentelemetry-js-contrib:tm-tedious-18-play
Repeating its commit message (because GitHub likes to hide those):

    tedious@18 adds its own .d.ts files. Compiling with them requires
    TypeScript v5, and either target:'es2022' for 'AggregateError'
    or using skipLibCheck:true in tsconfig.json.

    This change limits the update to TypeScript v5 to just while
    testing tedious@18 via test-all-versions' support for
    'peerDependencies'.

    THis also drops ts-mocha in favour of 'mocha --require ts-node/register'
    as was done on opentelemetry-js.git in https://github.com/open-telemetry/opentelemetry-js/pull/4840
  • It uses some of the work that you've done, and tries to limit some things (like not updating the typescript version in package.json).
  • I agree that TypeScript v5 is required to compile the test files with tedious@18. Given that we only need to do that for test-all-versions (TAV) testing, I used peerDependencies in ".tav.yml" for that (https://github.com/watson/test-all-versions?tab=readme-ov-file#peer-dependencies).
  • I limited some of the needed type changes in test/api.ts.
  • I also split out some of the versions in .tav.yml for minimum support Node.js versions. This wasn't completely necesasry because test/instrumentation.test.ts knows how to skip out if the current version of Node and tedious isn't supported.
  • I'm good with the switch to mocha --require ts-node/register. This was done a few months back in the opentelemetry-js.git repo. We should follow-up with a separate change to do the same for all the other packages in this repo.

on skipLibCheck

  • I found that skipLibCheck: true in "tsconfig.json" was necessary, otherwise the test code won't compile with tedious@18.

It would fail with:

../../../node_modules/tedious/lib/connection.d.ts:761:29 - error TS2304: Cannot find name 'AggregateError'.

761     loginError: undefined | AggregateError | ConnectionError;
                                ~~~~~~~~~~~~~~

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.

options

Please let me know which you would prefer:

  1. I could make a PR out of my branch for discussion and see about pushing that through, or
  2. You could take the few changes I have from yours. If you do take my changes, please take my (smaller) diff to the top-level package-lock.json file as well.

@kirrg001
Copy link
Contributor Author

kirrg001 commented Aug 12, 2024

@trentm Thanks so much for taking the time to review this.

I could make a PR out of my branch for discussion and see about pushing that through, or

This option sounds like the easiest. I'd suggest that you are opening your PR and I'll close mine :)

@kirrg001
Copy link
Contributor Author

Closing in favor of #2381

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for tedious v18
4 participants