chore: Fix lint warnings in instrumentation package#2404
chore: Fix lint warnings in instrumentation package#2404dyladan merged 5 commits intoopen-telemetry:mainfrom
Conversation
872604d to
97234e4
Compare
Codecov Report
@@ Coverage Diff @@
## main #2404 +/- ##
==========================================
+ Coverage 93.03% 93.04% +0.01%
==========================================
Files 137 138 +1
Lines 5069 5093 +24
Branches 1089 1096 +7
==========================================
+ Hits 4716 4739 +23
- Misses 353 354 +1
|
packages/opentelemetry-instrumentation/src/platform/node/instrumentation.ts
Outdated
Show resolved
Hide resolved
| const results = parseInstrumentationOptions(option); | ||
| instrumentations = instrumentations.concat(results.instrumentations); | ||
| } else if (typeof option === 'function') { | ||
| } else if (isInstrumentationClass(option)) { |
There was a problem hiding this comment.
nit: this and line 39 seem like overkill, especially as isInstrumentationClass is just checking if option is a function and not specifically that is a class / constructor. Especially this this really just causes more code to be generated than necessary (coming from a code / browser support minification perspective)
There was a problem hiding this comment.
Oh, and don't appear to be related to the listed linting issues.
There was a problem hiding this comment.
Replacing this function with typeof option === 'function' results in the following compile error:
Cannot create an instance of an abstract class.ts(2511)
The nice thing about this type guard function is that it implicitly casts the option to the desired type as well.
The isInstrumentation function can be removed though. I just added it to improve the readability of the code (by my personal standards!).
There was a problem hiding this comment.
That would be a side effect that the function is declaring that the object is of type option is new () => T (which could be added inline) as this gets compiled away.
So simplistically, you have a function that is kludging this. If you want a function I would suggest that we create this as a helper and call it something like isConstructor although that would still just check that it's a function.
There was a problem hiding this comment.
... declaring that the object is of type option is new () => T (which could be added inline) ...
That's actually a good idea. Can you tell me how to do it? I cannot figure out the syntax to do it in the if condition.
There was a problem hiding this comment.
It would require a change, but it could be done. The meta package could easily return a list of already new'd instrumentations. The constructor itself doesn't do any patching or have side effects.
There was a problem hiding this comment.
it's not pretty but something like this should work, hence my suggestion of a generic isConstructor helper
} else if (typeof option === 'function') {
instrumentations.push(new (option as unknown as (new () => InstrumentationOption))());
}
There was a problem hiding this comment.
I prefer disabling the eslint warning instead of cast to unknown then to something else which only pretends to be typesafe. If the call to new fails, then the user will get an error during process start. We can't guard against every possible case.
There was a problem hiding this comment.
It seems like the current solution is not preferrable. I will change it back to use any and disable the eslint for that line.
| ): AutoLoaderResult { | ||
| let instrumentations: Instrumentation[] = []; | ||
| for (let i = 0, j = options.length; i < j; i++) { | ||
| const option = options[i] as any; |
There was a problem hiding this comment.
actually any is valid case here. This will be coming from a user so it can be written in ts or pure js, I would not change that.
There was a problem hiding this comment.
If any is valid here, then the InstrumentationOption type should be changed?
Or the function parameter type should be any[] or unknown[].
There was a problem hiding this comment.
He is simply saying it is possible for the function to be called with bad inputs and saying you should guard against that. Unlike a real staticly typed language, we can always receive bad input. IMO failing during setup if bad inputs are passed is fine, but if something is easy to guard against I see no reason not to.
| const results = parseInstrumentationOptions(option); | ||
| instrumentations = instrumentations.concat(results.instrumentations); | ||
| } else if (typeof option === 'function') { | ||
| } else if (isInstrumentationClass(option)) { |
There was a problem hiding this comment.
I still think we should only allow
Instrumentation[]but that would need to be handled in a separate PR since it is breaking and quite a substantial change.
not really, the meta package will return array of instrumentations, and you still want to be able to do that,
[ getNodeAutoInstrumentations(), new MyOwnPackage()]
packages/opentelemetry-instrumentation/src/platform/node/types.ts
Outdated
Show resolved
Hide resolved
packages/opentelemetry-instrumentation/src/platform/node/instrumentation.ts
Outdated
Show resolved
Hide resolved
|
cc @alisabzevari could you rebase your PR ? there are conflicts :/ |
2cdb763 to
9045870
Compare
|
Done @vmarchaud, please have a look. |
related to #1093,
Which problem is this PR solving?
instrumentationpackage.Short description of the changes