angular / angular/angularfire

Six `firebase` entry points have no `@angular/fire` equivalent, so their exports are unreachable

Aperta
#3,755 0 commenti 0 reazioni 1 assegnatario Rivendicata da @armando-navarro Vedi su GitHub
comp: core type: feature
Lingua principale
TypeScript
Stelle
7.8k
Fork
2.2k
Merge medio
22h 28m
PR unite (30g)
6

Descrizione

### Summary

`firebase` 12.18.0 publishes 20 importable paths that are not `compat`. `tools/build.ts` re-exports 14 of them. Anything exported from the other six is unreachable through `@angular/fire`, so an app that needs it has to import from `firebase` directly and give up the Angular behavior AngularFire adds for that part of its code.

### The six unreachable paths

- `firebase/firestore/pipelines`
- `firebase/firestore/lite/pipelines`
- `firebase/auth/cordova`
- `firebase/auth/web-extension`
- `firebase/installations`
- `firebase/messaging/sw`

The two `pipelines` paths are recent: `firebase` 12.4.0 publishes no path containing `pipelines`, and 12.8.0 publishes two. The other four exist in 12.4.0 and so have been unreachable for as long as that has been the version the package is built against.

### Why this is separate from a wrapped module missing symbols

A missing symbol inside a path AngularFire already ships is fixed by re-running `tools/build.ts`, which regenerates that path's `src//firebase.ts` from the installed `firebase` and picks the new symbol up.

A missing path is not fixed that way, because there is nothing for the generator to regenerate. `tools/build.ts` only writes the `firebase.ts` file inside a directory that already exists, and the rest of that directory is written by hand. `src/firestore/lite/` is 8 files and 269 lines, of which only `firebase.ts` is generated.

### Things to consider

This is not a single mechanical change, and I do not think all six should be treated the same way:

- Whether to ship each path at all. `firebase/messaging/sw` runs in a service worker and `firebase/auth/cordova` targets a platform Angular apps rarely use, so an Angular wrapper may not be the right home for either.
- For each path that ships, every function in it has to be classified for wrapping, the same way the existing modules were.
- The cost is per path, roughly six or seven hand-written files each, so this may be better done a path at a time than as one change.

If you are blocked on one of these specifically, saying which one and what you are trying to do would help order the work. `firebase/firestore/pipelines` is the one with a request already attached to it, in [#3693](https://github.com/angular/angularfire/issues/3693).

Guida per i contributori

Apri la guida per i contributori

Valutazione

Questa issue non è ancora stata valutata.

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.