ref: Convert IITM and RITM to typescript

[Luca Forstner (lforst)]

No description provided.

[Abhijeet Prasad (AbhiPrasad)]

This makes it way harder to maintain this w/ upstream. Do we really need to convert rn?

[Luca Forstner (lforst)]

This makes it way harder to maintain this w/ upstream. Do we really need to convert rn?

Abhijeet Prasad (@AbhiPrasad) Hm.. It's a very valid point. And I am not sure what is best. Feel free to block me or think this through with me.

My thought process was that we will most likely end up modifying the packages in some way or another (like removing functionality around configuration that we don't need, maybe a slight adjustment here and there), and the type checking would give us actually a huge safety net in that case. I also thought that nowadays, syncing with upstream is likely not as huge of a pain as it has been before (?). It's all just my best guess on how things play out.

[Abhijeet Prasad (AbhiPrasad)]

there's a bunch of iitm improvements coming in the pipeline (see nodejs/import-in-the-middle#265 as an example), so I'd atleast hold off for a bit before doing the ts conversion.

[Luca Forstner (lforst)]

there's a bunch of iitm improvements coming in the pipeline (see nodejs/import-in-the-middle#265 as an example), so I'd atleast hold off for a bit before doing the ts conversion.

I also just saw those because your comment made me check haha. That particular PR changes 7 LOC of actual package code. Lemme actually try and sync based off this PR and see how tough it is.

[Luca Forstner (lforst)]

Development there picked up after like 6 months of almost inactivity. Great timing haha

[Stephen Belanger (Qard)]

Is there a reason we can't just upstream a typescript port so we don't need to maintain this alone? There has also been a bunch of desire expressed to unify IITM and RITM, might be worth just building a unified thing and donating that to the Node.js project to supersede the existing separate projects.

[Luca Forstner (lforst)]

Is there a reason we can't just upstream a typescript port so we don't need to maintain this alone? There has also been a bunch of desire expressed to unify IITM and RITM, might be worth just building a unified thing and donating that to the Node.js project to supersede the existing separate projects.

• I'd like us not to depend on upstream.
• We'd like to be able to do changes to IITM and RITM
• IITM/RITM are very annoying dependencies for customers because multiple versions of multiple vendors, e.g. Sentry, OTEL directly, and Braintrust versions may clash. Becomes immediately obvious once you use any combination of these tools in prod. You basically always have to apply an override to get rid of warnings everywhere.
• Maintaining a fork of a low-frequency repo is lim free nowadays.

[Stephen Belanger (Qard)]

• I'd like us not to depend on upstream.

I'd like the opposite. Why would we want to own something the community can maintain?

• We'd like to be able to do changes to IITM and RITM

Why? If there's something we need that they don't provide we can just contribute the changes for that.

• IITM/RITM are very annoying dependencies for customers because multiple versions of multiple vendors, e.g. Sentry, OTEL directly, and Braintrust versions may clash. Becomes immediately obvious once you use any combination of these tools in prod. You basically always have to apply an override to get rid of warnings everywhere.

So make it not clash? Like I said, we can make a new thing, but there's no reason for us to own it internally when we could let the ecosystem have it and contribute to it.

• Maintaining a fork of a low-frequency repo is lim free nowadays.

I disagree. It's an easy trap to fall into that burns more tokens than necessary and puts us in an unknown security position because we don't actually use the trusted thing that's actually getting proper security review. Standards exist for a reason, we should be involved in shaping them if we find they're insufficient for our needs, not cloning everything we depend on and maintaining it all ourselves.

[Luca Forstner (lforst)]

I'd like the opposite. Why would we want to own something the community can maintain?

Speed.

Why? If there's something we need that they don't provide we can just contribute the changes for that.

That requires bureaucracy that I'd like to avoid.

So make it not clash?

This PR is part of me trying to achieve that.

Like I said, we can make a new thing, but there's no reason for us to own it internally when we could let the ecosystem have it and contribute to it.

While I enjoy OSS, our primary goal is to build a good SDK for Braintrust customers, and us being able to react quickly to Braintrust user needs. The SDK is open to contributions, but I would argue right now it is not a big priority for us to come up with new open source projects.

we don't actually use the trusted thing that's actually getting proper security review

I don't think our security stance is much different from that of import-in-the-middle. We also have very capable people and mandatory code reviews. While IITM might be more targeted to scanning, we also have security audits (which I don't think IITM has?).

Standards exist for a reason

Even though IITM lives in the node.js org, I don't think that makes it a standard. IIRC that was more of an organizational convenience move for everybody involved in the OTEL ecosystem.