denoland
fix(otel): Fix unstable otel flag handling
This PR fixes the handling of the --unstable-otel flag, standardizing it with how all other unstable flags are parsed, using the has_unstable function.
Of course, because otel has to be initiated before all other config options, that is factored in, and this PR keeps all the special treatment of running before almost any other configs are processed that allows otel to startup as early as possible.
The previous handling of this flag was janky with manual parsing of incomplete flags, leading to errors such as the fact that adding "otel" to the "unstable" array in deno.json didn't enable it but adding --unstable-otel to the command did.
Closes #29477
@dsherret I know you did something similar and I'm very much hitting a wall. Do you know if there's any way to fetch the config without initializing a workspace?
Would it be insane to initialize otel a little later, like in the cli factory, even just as a fallback if it uses this type of unstable
Funnily enough, this "instability" of otel only applies because it's marked unstable. Self-fuffilling prophecy of sorts.
I'm new to contributing, just saw something I naively thought would be a simple fix, so feel free to ignore this if this is unhelpful/improper.
@knotbin this is actually a really though nut to crack. Thanks for the PR and sorry I didn't get to it sooner - I think we will stabilize Otel support in the next minor release so this will not be a problem anymore.
Great to hear! Yeah I didn't commit anything further but I did try a bunch of different things and of course none of them worked because the otel has to be initialized before the workspace is.
It's kind of a paradoxical unstable feature 😅