[go: nahoru, domu]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Exposing APIs required by firebase-tools as non-internal #533

Open
merlinnot opened this issue Jul 19, 2019 · 4 comments
Open

Exposing APIs required by firebase-tools as non-internal #533

merlinnot opened this issue Jul 19, 2019 · 4 comments
Labels
type: feature request

Comments

@merlinnot
Copy link
Contributor

Rationale

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

That's what we get for relying on internal APIs

  1. 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
Copy link
Collaborator

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

@samtstern
Copy link
Contributor
samtstern commented Jul 19, 2019 via email

@mbleigh mbleigh removed their assignment Feb 10, 2021
@elvisun
Copy link
Collaborator
elvisun commented Jun 30, 2021

@inlined Is this something we can address in V2?

@inlined
Copy link
Member
inlined commented Jul 10, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: feature request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@mbleigh @inlined @elvisun @samtstern @merlinnot @taeold @google-oss-bot @thechenky