Exposing APIs required by `firebase-tools` as non-internal

[merlinnot]

Rationale

1. From TypeError: _onRequestWithOpts is not a function firebase-tools#1480 (comment)

That's what we get for relying on internal APIs

2. Unexpected side effect of @hidden to @internal migration - exposed definitons #529

Overview

It seems that issues caused by the necessity to expose internal APIs and usage of these APIs in firebase-tools starts to hurt. We should find a way to expose necessary information in a better way, that would:

• allow us to get rid of stripInternal, @internal and @hidden by making methods and properties actually not exposed (private, not exported, ...);
• raise awareness of these APIs being used by other repositories, to make it more understandable that someone relies on it, to force us to think of changes to these APIs as breaking.

I'm opening this issue as a place where we can discuss possible designs and consequences, I'd be willing to work on the implementation if we decide on a certain design.

@thechenky @samtstern If you think it's a good idea, could you ping all of the people who should be involved?

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[samtstern]

Thanks for bringing this up! I think @abeisgoat had an idea for how we (firebase-tools) could no longer rely on internal APIs of firebase-functions but he won't be in the office until Monday to tell us about it.

…

On Fri, Jul 19, 2019, 1:46 AM Google Open Source Bot < ***@***.***> wrote: I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#533?email_source=notifications&email_token=ACATB2T2KGSCNXMH76FXCRTQAF5PDA5CNFSM4IFDZ3V2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2LAJ6I#issuecomment-513148153>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACATB2WXCCQAJ5VKJSUNHZ3QAF5PDANCNFSM4IFDZ3VQ> .

[elvisun]

@inlined Is this something we can address in V2?

[inlined]

The general goal is that all interaction between the CLI and the SDK will be done with HTTP and not raw JS, so it would be impossible to have any cross-repo dependencies in the future. That, of course, only works though once we successfully wrap all these thorny edge cases into a nice and documented container contract.