Packaging now has src, test

[akauppi]

Noticed that 0.900.15 packaging includes test, src and maybe other unrelated directories. Would be nice not to ship these:

$ ls -al node_modules/@firebase/auth/dist/esm2017/test/
total 0
drwxr-xr-x   4 asko  staff  128 25 Hel 19:21 .
drwxr-xr-x  16 asko  staff  512 25 Hel 19:21 ..
drwxr-xr-x  15 asko  staff  480 25 Hel 19:21 helpers
drwxr-xr-x   3 asko  staff   96 25 Hel 19:21 integration

---

As a meta comment: can answers be enabled for the General section, too? I noticed moving discussions to Q & A since there I can mark them answered, but this erodes the "ask the community" focus of it.

[Feiyang1]

Thanks for the feedback. Those folders are auto-generated by TS. We didn't make an effort to clean these up because they are harmless. We should probably look into cleaning them up, but it would be low priority at the moment. Do you just find them annoying or is there any practical concern?

I don't see an option to enable marking answers in General section. Maybe it's a Github limitation? @samtstern Any ideas?

[akauppi]

@Feiyang1 There's no practical concern. I'm just ultra tidy about my packaging, I guess.

[akauppi]

Found one practical concern. The extra cruft likely slows down IDE indexing, which I need for being able to dive into Firebase code.

$ du -h node_modules/@firebase
...
128M	node_modules/@firebase

[samtstern]

Oh wow. I had always thought that npm install firebase was slower than most other packages but I figured I must be imagining the effect. If we're pulling 128MB of code each time that would explain it!

Although doing a quick check ... most of the weight comes from .js.map files which are useful to distribute. Also @firebase/firestore alone is 62MB 🤯

For a quick visualization: blue are .js.map, green are .js, re are .ts. Everything in the big yellow box on the left is Firestore.

[akauppi]

I did some trimming on my own, and came down to:

 51M	node_modules/@firebase

Tried to only throw out packaging I don't need to (eg. cordova, esm5), without affecting the functionality of the overall delivery. I think much of the burden is because of multiple, overlapping build targets. Did you see my analysis here?

---

Edit: I think ~30MB is a meaningful target for the packaging.

I got Firestore down to 9MB.

[akauppi]

I did a little repo firebase-slim to gather the pieces I'd consider unnecessary. It's obviously more complicated than that, and this is where I yield. My interest is merely in the ES modules compatible browsers (and maybe ES modules compatible node, which I think could share the exact same packaging).

Was surprising to see that node_modules/firebase is rather big to begin with.