Update odsp-driver package tests to build and run in ESM

[noencke]

Description

Updates the package test scripts to build and run in ESM in addition to CJS.

This required updating a few places where functions were being mocked by the sinon library.

The sinon stub() function mocks a given function on a given object. For top-level functions, this meant that the exporting module object's reference to the function was being replaced with the stub. This is no longer permitted in ES6 since module objects are readonly.

To solve this, there is now a helper function mockify() which can decorate a function with a property that allows it to be easily mocked by sinon. The helper works by wrapping the function in a new function with the same signature; the inner function delegates to a property that has the actual function implementation (which defaults to the original function). This pattern makes it easy to update this package without making significant changes to the code flow. Rather, the problematic functions and their mock sites have been updated to use this helper. One function, fetchHelper was already a wrapper around fetch (which was being mocked) - so it has been updated to use a similar pattern but in a slightly different way.

Also replaces two usages of the CJS-supported __dirname with the _dirname pattern (see dirname.cts) to accommodate relative file paths in both CJS and ESM.

Copilot reviewed 5 out of 15 changed files in this pull request and generated no comments.

Files not reviewed (10)

• packages/drivers/odsp-driver/package.json: Language not supported
• packages/drivers/odsp-driver/src/test/joinSessionCacheTests.spec.ts: Evaluated as low risk
• packages/drivers/odsp-driver/src/test/fetchSnapshot.spec.ts: Evaluated as low risk
• packages/drivers/odsp-driver/src/test/socketTests/socketTests.spec.ts: Evaluated as low risk
• packages/drivers/odsp-driver/src/test/joinSessionPeriodicCall.spec.ts: Evaluated as low risk
• packages/drivers/odsp-driver/src/test/odspDriverUrlResolverForShareLink.spec.ts: Evaluated as low risk
• packages/drivers/odsp-driver/src/test/socketTests/deltaConnectionUpdateTests.spec.ts: Evaluated as low risk
• packages/drivers/odsp-driver/src/odspUtils.ts: Evaluated as low risk
• packages/drivers/odsp-driver/src/test/mockFetch.ts: Evaluated as low risk
• packages/drivers/odsp-driver/src/vroom.ts: Evaluated as low risk

Comments suppressed due to low confidence (1)

packages/drivers/odsp-driver/src/fetchSnapshot.ts:697

• Ensure that the changes to use mockify for downloadSnapshot are covered by tests.

export const downloadSnapshot = mockify(

[CraigMacomber]

this pattern breaks IntelliSense for the function, and also makes it easy for any code using the function in this package to call either one (and isn't super clear which one should be called.

I think it would be better to avoid having two separate functions in scope here: if you want all callers to use this version, I think a decorator would be a better way to wrap it as that would keep the non-wrapped version out of scope and allows the IntelliSense/docs to function properly. It would also be more concise.

[noencke]

Well, as I mentioned in this comment, I can just inline it instead, so there is no rename+export. I like that better anyway, it just ruined the diff for this PR.

When you say decorator do you mean an actual TS decorator? I was under the impression that you can only write those for class members, not free functions.

[CraigMacomber]

Apparently, you are right, they don't work on free functions.

If you don't inline them, I think you should nave the version you won't want people using something like fooInner instead of naming the one you do want people to use mockableFoo. Also leave the doc comments on the actually exported one (and maybe link or inherit doc the inner one to it).

I do think inlining it would be better, though refactoring things do we don't need mocking in the first place would be best: adding testing only hooks to production code is always a bit sketchy as it implies the code itself isn't flexible enough to do what tests need which is generally a bad sign.

[noencke]

You're right that renaming the inner helper would be better than renaming the outer exported function (because otherwise, code calling the function from within its module of declaration will accidentally use the wrong one). However, I just went ahead and in-lined the calls. The diff in this PR now looks worse, but the actual code looks better :)

I also took a look at refactoring so that e.g. fetch is injected rather than mocked. It's of course possible, but not trivial, and is beyond the scope of this PR IMO.

[CraigMacomber]

I think the title and description are out of date as this works on both cjs and esm now right?