[Question] Could this be used to visualise complex yarn script nonsense?

[alsuren]

Crazy idea: I don't know whether this is in-scope for your project, or whether I should build it myself, but yours feels like the most similar project to what I'm imagining, so I thought I'd ask anyway.

At work, we have a bunch of complicated scripts in our package.json, and they depend on each other in nontrivial ways. Running yarn build will spawn a handful of codegen tasks in a carefully orchestrated manner, with a bunch of parallel tasks specified manually using the concurrently js package. It's like make but strictly worse. I want to rip it out and replace it with something that has an explicit concept of dependencies, and can avoid duplicated work. I've been putting off wrapping my head around the problem because I don't have a good way to visualise it at the moment.

I recently discovered (via https://stackoverflow.com/a/58188828) that if you run yarn config set script-shell $PATH_TO_WRAPPER_SCRIPT then you can change which shell runs your scripts.

I was thinking that I could make a tiny go/rust/typescript/bash program that:

• reads the arguments (normally yarn will call it as sh -c "$BODY_OF_SCRIPT")
• starts a span
  • named "$BODY_OF_SCRIPT"
  • as a child of any existing span that it finds in its environment variables
  • exports the span id into an environment variable so that it can be found by child processes
• spawns sh -c "$BODY_OF_SCRIPT"
• waits on the shell process to complete
• reports the span to the otel collector over http
• exits with the same exit code as sh

If I had this then I would be able to visualise the existing build process, and the whole thing would be a bit less scary.

a) Does the opentelemetry-shell project support linking parent/child relationships between shortlived child shells using environment variables?
b) If I built my idea using opentelemetry-shell, would you be interested in accepting it as an example in this repo?

extra context for if I decide to write it from scratch

My company is currently using datadog, and getting that set up locally was reasonably straightforward. I've not tried piping arbitrary opentelemetry nonsense into it, but it probably wouldn't be that hard. In the worst case I guess I could run zipkin in a docker container or something as a one-off. If I was building it from scratch, I would probably hack it together in a datadog-specific way, even though a standard otel-based implementation would be more useful to more people.

Thinking about it, having a README that says docker run $PORT_FORWARDING_OR_WHATEVER zipkin in one tab and yarn config set script-shell /path/to/shelemetry && yarn build && yarn config delete script-shell && open https://localhost:$ZIPKIN_GUI_PORT/ then it will be easy for people to get started with it with no additional setup or dependencies.