refactor(shared-object-base): Improve typing in legacy+alpha API surface

[alexvy86]

Description

Warning

This is intended to go into the 2.20 release because it includes breaking changes to the legacy+alpha API surface (tracking issue: #23236). Do not merge it before that.

Updates some types in the legacy+alpha API surface of the @fluidframework/shared-object-base package. Mostly improving type safety by replacing any with unknown, and a few any with void where that was the correct type.

Also updates some code in response to the changes above, like call sites of the affected APIs now having to do casts themselves instead of relying on the any they were getting before.

Breaking Changes

The breaking changes affect only the legacy+alpha API surface.

Reviewer Guidance

The review process is outlined on this wiki page.

AB#26129

[markfields]

Curious why there are no type validation test changes needed here?

[alexvy86]

Curious why there are no type validation test changes needed here?

Great question, I hadn't thought of that. It seems to be the fact that TS just gives up on any kind of type validation whenever it sees an any. So that's something our type-tests don't seem to be able to protect us from (replacing an any with something else, or viceversa).

I confirmed by adding a small snippet with functions that change their inputs and outputs from unknown to any, and type tests for those don't complain either:

[markfields]

Curious why there are no type validation test changes needed here?

Great question, I hadn't thought of that. It seems to be the fact that TS just gives up on any kind of type validation whenever it sees an any. So that's something our type-tests don't seem to be able to protect us from (replacing an any with something else, or viceversa).

I'm remembering now - last I checked, the type tests' TypeOnly mapped type doesn't try to compare function signatures, so I think your experiment will behave the same with any type there, not just any?

[alexvy86]

I'm remembering now - last I checked, the type tests' TypeOnly mapped type doesn't try to compare function signatures, so I think your experiment will behave the same with any type there, not just any?

Yeah, good catch. Example 1 below shows that with a string->number return type change (and the same happens with free functions). That said, it seems it's also true that we don't get protection from any->unknown changes even when they're on props (example 3), where a string->number (example 2), does complain:

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> [email protected] ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> [email protected] serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> [email protected] check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  170492 links
    1603 destination URLs
    1838 URLs ignored
       0 warnings
       0 errors

[alexvy86]

@Josmithr @markfields any further comments here? The integration pipeline with Loop passed so it should be good to merge.

[Josmithr]

It would be good to add a changeset for this, but otherwise looks good to me!