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

[bug] @types/ioredis4 included in regular non-dev dependencies of ioredis instrumentation #1931

Closed
jballentine-sharpen opened this issue Feb 9, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@jballentine-sharpen
Copy link

jballentine-sharpen commented Feb 9, 2024

Here is the line in question: https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/plugins/node/opentelemetry-instrumentation-ioredis/package.json#L72

This should be moved to devDependencies. This mistake is currently causing my company's CI to fail due to it not being able to find this package, even though it shouldn't need this package as it should be a dev dependency.

You can even see it included in the dependencies list here: https://www.npmjs.com/package/@opentelemetry/instrumentation-ioredis?activeTab=dependencies and when you click on it, it doesn't exist.

Related to this: This package doesn't actually seem to exist. Is ioredis4 a typo? @types/ioredis does exist, and when you go to that package is says This is a stub types definition. ioredis provides its own type definitions, so you do not need this installed., so I think this types package isn't even necessary to begin with.

After looking at it again, it looks like this is a custom specification to use an older version of the @types/ioredis package. Why are you doing this when you use ioredis 5? I feel like this can just be safely removed

What version of OpenTelemetry are you using?

  • 0.41.1 of auto-instrumentations-node

What version of Node are you using?

  • 14 (not really relevant for this)
@jballentine-sharpen jballentine-sharpen added the bug Something isn't working label Feb 9, 2024
@jballentine-sharpen
Copy link
Author

After looking at the source more, I see why you did it this way.

We also upgraded the service in question to use a later lockfile version as it was still on 1. As a result, the issue is now gone. Sorry for the false bug report

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant