Splitting the index.d.ts file into smaller files

[hiranya911]

Our index.d.ts file is massive and continues to grow (5800 lines as of today). This makes locating specific elements and changing them difficult. This PR attempts to split the file into a number of smaller components by moving the service-specific API definitions to separate files.

The downside of this change is that, because of the limitations in TypeScript, we have to explicitly re-export each public type in the index.d.ts file again:

// index.d.ts

import * as _auth from './auth';

declare namespace admin.auth {
  export import Auth = _auth.admin.auth.Auth;
  export import UserRecord = _auth.admin.auth.UserRecord;
  // and so on...
}

This means whenever a new API/type is added, we have to update 2 files instead of one. I still feel like having smaller files outweighs this drawback. This issue is also likely to go away in a future version of TypeScript (microsoft/TypeScript#10187). Regardless, I'd like to see what others think about this change.

I have verified the TypeScript integration tests, and the doc generation pipeline with this PR and did not find any issues.

[egilmorez]

Looks like a good idea to me. I grew accustomed to reference update flows that required multiple file edits in previous versions, so no big deal there.

[bojeil-google]

Didn't check the details, but seems fine to me

[bojeil-google]

Isn't this creating a circular dependency? Maybe a separate file for App and Error should be created? Similarly in the other files.

[hiranya911]

It looks like TS allows this kind of circular dependencies in typings. It's really not possible to avoid it in our API, since our App type has methods like auth() and database() that returns admin.auth.Auth and admin.database.Database respectively. So we essentially have this dependency chain:

• admin.auth.Auth references admin.app.App.
• admin.app.App has a method auth() that returns admin.auth.Auth.

Same applies to all other modules.

[lahirumaramba]

Same concern regarding the circular dependencies... otherwise LGTM